REMI: Building an Enterprise Multi-Agent GTM Operating System

REMI was not one clever prompt or one fixed workflow. I designed the operating layer for building and running specialized business agents: structured onboarding, manager and worker roles, versioned skills, tool access, long-lived execution, persistent artifacts, human approval, and integrations into the systems employees already used.

The point was to move from “an agent can generate this” to “a business can operate this.” That required architecture, but it also required forward-deployed engineering: sitting with employees, watching where the system collided with incentives and handoffs, and having the difficult conversations that only appear after a demo meets real work.

The scale figures above describe the broader production profile around this work. The interface evidence below documents the system architecture; it is not presented as aggregate telemetry for those figures.

The business problem

Marketing teams were sitting on real assets—research, positioning, customer psychology, campaign history, brand knowledge—that did not reliably become executable output. Context lived across people and tools. Every handoff lost detail. Production depended on whoever could reconstruct the business in their head that week.

The first challenge was generation. The durable challenge was everything around it: context, authority, observability, recovery, integration, and adoption. A production agent needed to know what it could do, where truth lived, what evidence it had created, when it had to stop, and which human owned the next decision.

The operating system

System architecture

A GTM operating system, not a content generator

Company knowledge and live signals move through orchestrated agents, explicit human authority, operational execution, and a measurable learning loop.

The sequence is conceptual, not a fixed linear runtime. Real runs can branch, retry, preserve intermediate artifacts, and return for revision before crossing an authority boundary.

At the center was a long-running strategist pattern. It could spend an hour or more moving from research to positioning and campaign strategy, then hand work to specialists. Splitting the work was not cosmetic: one agent trying to carry company context, research, planning, asset production, and tool state eventually became incoherent.

Context retrieval evolved through three real generations: vector search, a graph-based model, and finally a filesystem and repository layer. The last approach made company knowledge inspectable, versionable, and easier for both humans and agents to navigate. That work later expanded into the separate Company Brain case study.

Public blueprint

Make organizational context an engineered layer.

The Ask Your Org Blueprint turns the company-context lessons behind REMI into a platform-general architecture for sources, ownership, permissions, and escalation.

Get the blueprint Explore the proof

System evidence

The platform, not just its outputs

Four product surfaces show the operating model: agents are configured, grounded in company context, composed into workflows, and connected to real business systems.

REMI agent creation interface with manager and worker types, instructions, integrations, skills, and model selection — **A reusable manager/worker model**
New agents could be created as managers or workers, then equipped with instructions, specialist agents, integrations, skills, and an explicit model choice.
Open full-size evidence →

Engineering decisions

Build a factory, not another fixed automation

Constraint: The company needed different agents for different clients, GTM channels, tools, and authority levels.
Decision: Make agents configurable from manager/worker topology, instructions, model, skills, integrations, and delegated specialists.
Consequence: New production cells could be assembled without rewriting the runtime for every use case.

Treat skills as versioned operating contracts

Constraint: Prompts were becoming large, coupled, and difficult to improve safely.
Decision: Move repeatable procedures into named, versioned skills with explicit inputs, outputs, and forbidden actions.
Consequence: Capabilities could evolve independently, and authority boundaries became inspectable rather than implied.

Separate canon, workbench, and memory

Constraint: Long-running agents needed durable context without turning every recollection into organizational truth.
Decision: Use repositories for canonical knowledge and operating records, session workspaces for temporary execution, and memory only for soft recall.
Consequence: The system could learn without silently rewriting company truth. Canonical changes still required review.

Make authority explicit

Constraint: Agents were acting on public content, business data, and external tools where a wrong write mattered.
Decision: Allow reading and drafting where appropriate, but require confirmation for external writes, publishing, pull requests, and knowledge promotion.
Consequence: Automation could move quickly inside a bounded workspace while humans retained accountability at consequential edges.

Observability was part of the product

I traced thousands of agent runs from the beginning. The useful unit was not a final chat message; it was the execution history: delegated tasks, tool calls, run events, intermediate artifacts, failure points, and the exact place a human intervened.

That changed how the system was engineered. Failures stopped being vague reports that “the agent got confused.” They became evidence about context loss, tool contracts, state transitions, permission design, or an overly broad responsibility. Stability over runs longer than an hour came from reducing those ambiguities—not from asking the model to try harder.

The same architecture produced a concrete, public implementation: an agent-native SEO department that coordinated research, writing, rich media, Airtable state, human review, and Framer publication.

The revenue-traceable engine

The later REMI GTM Engine design pushed the operating model one level further. Instead of organizing around tasks or content types, it organized work around a commercial lineage:

RevenueTarget → Decision → Assignment → Run → Artifact → Measurement → Assessment → Learning → RevenueEvent

This is the important distinction between a project tracker and a GTM engine. An article is not just “content.” It is an artifact produced by an assignment, caused by a decision, traced back to a revenue target, guarded by deterministic checks, and paired with a measurement plan.

The first implementation slice used SEO as a controlled vertical and encoded generic objects as repository records. The broader ontology and decision layer were still frontier architecture in progress. I am not presenting every part of that model as a finished production product; I am presenting the engineering direction, the implemented substrate beneath it, and the first executable slice.

Forward-deployed engineering

The work happened beside the business, not behind a requirements document. I worked with employees to introduce agents into existing roles and workflows, watched how people actually used them, and dealt with the uncomfortable questions: Who owns an answer? What happens when sources disagree? Which actions may be autonomous? Where does review become a bottleneck? When does a new system threaten an existing role or incentive?

Those conversations are part of enterprise agent architecture. A technically capable system that cannot survive permissions, ownership, adoption, and organizational reality is still a demo.

What this system proves

REMI demonstrates the full arc I care about: agent architecture, production infrastructure, GTM domain modeling, and deployment inside a real organization. The visible product is a factory for creating and operating agents. The deeper work is the control system around them—context, contracts, traces, gates, integrations, and a path from activity to business outcome.