Kleos

Your autonomous go-to-market operator. Onboard by conversation, approve the strategy, watch it run the motion.. research to booked meetings, with every action gated and you holding the kill switch.

Comment

Building an AI That Does Your Go-To-Market — So You Don't Have To

A build log from the Kleos9 project.

The uncomfortable truth that started this

Building is easier than it's ever been. Agents write code, ship features, spin up infra in an afternoon. And yet the graveyard of great products keeps growing — because the hard part was never building. It's getting anyone to care.

Go-to-market is where builders go to struggle. Positioning, prospecting, cold outreach, reply handling, booking, CRM hygiene — it's a specialist discipline that demands either an expensive hire or your own undivided, full-time attention. Most founders have neither. So the product sits there, quietly excellent, unheard.

We kept circling one question: if agents can build the product, why can't an agent run the motion that sells it? Not a template generator — an actual operator that does the end-to-end work a fractional head-of-growth would, and plugs into the tools teams already use. That's Kleos9.

This is a first local-first build, not a full production deployment yet. It already shows the full operating shape: safe onboarding, planning, outreach mechanics, and end-to-end evidence capture in one place.

What it does

You onboard your product with a short, guided conversation:

  1. Paste product material (documents, links, pricing, positioning notes).
  2. The Expert creates a structured knowledge base.
  3. It proposes positioning, claims, and a campaign plan.
  4. You review each item and choose approve / edit / reject.
  5. On approval, the system runs the sales-motion:

learn the product → stress-test it → forecast outcomes → make leads buyer-neutral → run campaigns → hold conversations → convert → learn and improve

Buyer-neutral leads are a core design choice: a lead may be a person, an organization, both, or neither-yet. A conversion can be a booked meeting, signup, purchase, subscription, or custom event.

The operator interface is always in one guided path:

Product → Strategy → Leads → Campaign → Conversation → Conversion → Learning

Every external action goes through a safety gate in the Gateway before any provider call:

  • approvals and kill switch
  • suppression and grounding checks
  • idempotency and duplicate prevention
  • complaint/bounce guardrails
  • graded decision rules

So the system is autonomous only where policy allows it. It does not publish, book, write to CRM, or spend money by itself.

The architecture

This section matches the README Architecture at a glance: Architecture at a glance

                         +------------------------------+
                         |            Owner             |
                         | approvals · policy · switch   |
                         +--------------+---------------+
                                        |
                                        v
                         +------------------------------+
                         |            Deck              |
                         |        owner console         |
                         +--------------+---------------+
                                        |
                                        v
                         +------------------------------+
                         |            Expert            |
                         | GTM judgment · playbooks     |
                         +------------------------------+
                                       |
                              +--------+---------+
                              |                  |
                              v                  v
                         +------------+      +------------------+
                         |   Engine   |      |     Gateway      |
                         |  Temporal  |      | safety checks    |
                         | durable    |      | grounding        |
                         +-----+------+      +---------+--------+
                               |                   |
                               v                   v
                 +-------------------------+   +-----------+
                 | Memory (engine state)    |  |  Modules   |
                 +------------+------------+   +------+-----+
                              |                     |
                              +---------------------+
                                                    |
                                                    v
                                            +---------------+
                                            |  Providers    |
                                            | external APIs |
                                            +------+--------+
                                                   |
                                                   v
                                            +---------------+
                                            | Action        |
                                            | Receipts      |
                                            +------+--------+
                                                   |
                                                   v
                                            +---------------------+
                                            |       Memory        |
                                            | events, claims,     |
                                            | leads, learning     |
                                            +---------------------+

What this means in plain terms:

  • Owner controls approvals.
  • Expert plans GTM actions.
  • Engine runs long actions over time.
  • Gateway enforces policy before every external call.
  • Modules call providers.
  • Memory keeps history, claims, leads, and outcomes.

Current module categories are:

  • data-provider (verification and enrichment)
  • crawler (research input)
  • mail-cold (cold outreach mechanics)
  • campaign-runner (campaign dispatch and lifecycle)
  • thread-runner (reply and conversion handling)
  • booking (calendar booking flow)
  • crm-sync (Twenty write-through and reconciliation)
  • mail-optin (opt-in nurture)
  • publisher (content artifact generation and preview/export)
  • doorstep
  • ads

External providers used behind Gateway are: Twenty, Cal.com, Reacher, Firecrawl, Mailgun, and Listmonk. Ad account publishing and spend are intentionally out of scope in current local behavior.

How we built it

We built it spec-first, and let coding agents do the typing.

Before any implementation, we wrote a full spec in:

  • architecture and module contracts,
  • hard invariants,
  • workflows and state flow,
  • and build order.

We used parallel subagents so work moved in parallel:

  • one team on the Orchestrator and core behavior,
  • one on LLM routing and response handling,
  • one on onboarding UI and deck flows,
  • one on modules and adapters,
  • one on Temporal workflows and workers,
  • one on local compose and infra.

Under the hood: TypeScript services for Deck, Expert, Gateway, and Engine; Temporal for deterministic long-running workflows; MongoDB as the system memory; and an LLM router so core logic is provider-agnostic.

Challenges

This work has several active design and operating challenges.

  1. Connecting many independent services through one safe control plane. Each provider has its own API, auth, schema, and failure behavior.
  2. Keeping long-running journeys deterministic and restart-safe in Temporal. Workflows must survive pauses, crashes, and retries without duplicating actions.
  3. Reconciling with an external CRM without creating duplicate people, companies, or activity records.
  4. Preserving the separation between judgment and execution. The Expert should decide what to do; modules should only do what is mechanically safe.
  5. Making LLM output reliable for strict machine pipelines. The LLM path needs bounded validation and repair for inconsistent outputs.

Accomplishments

A genuinely conversational onboarding that streams the Expert's reasoning and renders strategy as inline approval cards. An Orchestrator that durably walks S1→S12 and hands campaigns to real Temporal workflows. Real CRM write-through to a local Twenty, and end-to-end proof of the campaign → reply → book → reconcile loop with zero unintended external effects.

What we learned

  • Codex can build genuinely complex systems — when the spec is clear. This work showed that most friction came from underspecified edges. When the contract was precise, development moved fast. When it was not, teams interpreted differently and duplicated effort.
  • The right seam is judgment vs. mechanics. Putting all the thinking in one core and making everything else a replaceable hand is what let us parallelize the build safely and lets the motion scale by installing tools — it's the single decision that paid off most.
  • Autonomy has to be gated to be usable. The kill switch, approvals, grounding, and suppression aren't friction; they're what let a founder say "let it run" without fear — and they're what let agents build the risky parts without anyone getting hurt.
  • Distribution deserves the same rigor as the product. Treating GTM as an engineered system — invariants, gates, a spec — is what makes it automatable and trustworthy.

What's next

The system has moved from early local-only behavior toward broader production-readiness, but the work is still about safe, complete real-world operation.

Close the loop on live outreach. Link every module into one running motion, connect the real mail services (Mailgun outbound + signed inbound routes), and let the agents actually run the conversation — detect a reply the moment it lands, classify intent, draft a grounded response, and either send it or escalate to you. The mechanics already exist behind the gateway; the next step is wiring them to real seats and letting the conversationalist agent carry a live thread from first reply to booked conversion.

Go from ad studio to ad deployment. Today the platform generates, previews, and exports ad artifacts — no spend, by design. Next we connect Meta Ads and Google Ads as first-class modules so campaigns can be launched, audiences pushed, and budgets managed directly from Kleos9 — still behind the same grade/autonomy/kill-switch gates, so nothing goes live without your approval and every dollar is auditable.

Harden the path to production. Continue improving the LLM reasoning path (tolerant structured output + bounded repair), complete one-command full demo reliability across the full container stack, finish attribution and learning readiness, and finish connected-provider profiles. Then, with explicit authorization, run a live pilot: real seats, real sends, human-approved actions, and measured deliverability/learning over time.

Enable real posting. To enable real posting, we need to add the chosen platform’s OAuth/API adapter and connect your account. Kleos9 could then publish approved posts and store the resulting post URL and provider receipt. Advertising-account publishing is separate and remains disabled.

Because you shouldn't need to be a GTM pro, or go full-time on it, to get your product in front of the people who need it.

Built With

Share this project:

Updates