Agents Authoring Agents: What We Learned from Wiring Tandem's Docs to an LLM

I've been building Tandem as an open-source runtime for production AI agents. Today, I hit a moment that changed how I think about the runtime itself.

I wanted a daily competitor research workflow. Instead of writing it myself, I described the goal in a single paragraph to an LLM that had access to Tandem's documentation MCP server. It returned a complete, schema-correct mission blueprint: schedule, triage gating, memory policy, Notion handoff, and the rest.

I pasted that blueprint into Tandem's automation wizard. It ran. It works.

What mattered most was not that the LLM produced something plausible. It produced the right shape on the first try because it read Tandem's docs through MCP and treated them like an instruction set, not a pile of pages.

What made it possible

Most agent frameworks ship documentation for humans: readmes, tutorials, PDFs, and blog posts. LLMs can ingest those materials, but they often miss the details that matter, guess at abstractions, and produce half-working code.

Tandem's docs are exposed as an MCP server at tandem.ac/mcp. That means the model can call structured tools instead of scraping prose:

• search_docs for targeted queries
• get_doc to fetch a specific page
• get_tandem_guide for curated task guides
• recommend_next_docs for related material
• answer_how_to for synthesized answers grounded in the corpus

That changes the job of documentation. It stops being static reference material and becomes a machine-readable interface for authoring.

The blueprint it produced

From that one paragraph, the LLM returned a full mission plan. In shortened form, it looked like this:

• mission name: daily_competitor_monitoring
• schedule: daily at 8:00 in Europe/Budapest
• memory policy: project-scoped reuse only
• stages:
• triage_gate for a cheap first pass
• research when has_work is true
• notion_handoff to publish the result

Three details are worth calling out.

First, the triage_gate stage used metadata.triage_gate = true. Tandem's engine understands that flag and cleanly skips downstream stages when the cheap first check returns has_work = false. The LLM picked up that pattern from the docs and applied it correctly without being told.

Second, it defaulted to project-scoped memory instead of global memory. That is the behavior the docs prescribe.

Third, each stage included clear input and output contracts. The workflow was not just a list of actions; it was a typed pipeline where every stage knew what it produced and what the next stage consumed.

Why this matters

We are moving into a world where LLMs increasingly author the systems they participate in. Claude writes Claude workflows. Cursor writes Cursor extensions. Agents describe what they want, and other agents assemble it.

In that world, the frameworks that win are not necessarily the ones humans prefer to hand-write. They are the ones an LLM can author correctly on the first try.

That is a different design goal, and most agent frameworks were not built for it.

The implication goes beyond convenience. If an agent can author a workflow, it can author another agent. If it can author another agent, it can eventually operate the runtime itself — reading its own state, identifying gaps, and creating new automations to fill them.

We have started calling that pattern a meta-agent: an agent whose job is to run the runtime.

A concrete meta-agent: Self-Operator

The meta-agent we designed for Tandem runs once a week. Its job is to inspect what the company has been doing, identify automation gaps, and close them.

At a high level, the flow looks like this:

flowchart TD
 A[Weekly schedule trigger] --> B[Read strategic context from Notion]
 B --> C[Query Tandem docs MCP for current capabilities]
 C --> D[Inventory connected MCPs via mcp_list]
 D --> E[Reason over gaps: what should exist that doesn't]
 E --> F{Gap identified with confidence?}
 F -->|Yes| G[Author new automation via automationsV2.create]
 F -->|No| H[Write weekly report]
 G --> H
 H --> I[Publish to Notion Weekly Self-Operator Report]

Every step uses a primitive Tandem already has. Authentication is a single engine token. MCP discovery is built in. Automation creation is a direct route. Memory is project-scoped. Docs are queryable.

The meta-agent is not doing anything magical. It is simply using the runtime the way the runtime was designed to be used, except the operator is itself an agent.

The safety problem

Letting an agent create automations raises the obvious question: what prevents it from creating automations that should not exist, or modifying ones a human created?

Policy-based protection gets you part of the way there: narrow mcp_policy, no delete tools exposed, and a constrained surface area. That is enough for a first version. It is not enough for a production system that enterprise buyers can trust.

The stronger answer is provenance-based ownership. Every automation records who created it, and permissions flow from that provenance:

flowchart LR
 subgraph Humans
 H[Human user]
 end

 subgraph Agents
 A1[Agent X]
 A2[Agent Y]
 end

 subgraph Automations
 HA[Human-created automation]
 AA1[Agent X automation]
 AA2[Agent Y automation]
 end

 H -->|full access| HA
 H -->|full access| AA1
 H -->|full access| AA2

 A1 -->|full access| AA1
 A1 -.->|read only| HA
 A1 -.->|read only| AA2

 A2 -->|full access| AA2
 A2 -.->|read only| HA
 A2 -.->|read only| AA1

The rules are simple:

• Humans can do anything to any automation
• Agents can read any automation for discovery and context
• Agents can modify and delete only automations they created
• Agents can never delete human-created work
• Agent deletions are logged and reversible for a retention window

Humans can also grant an agent modify rights on a specific human-created automation. That grant should be scoped, revocable, and audited like any other action.

The key architectural line is this: ownership enforcement lives at the engine route layer, not in the SDK. An agent with an engine token cannot bypass ownership by calling HTTP directly, because the server enforces the rule regardless of client path.

The minimum schema

For anyone building a similar system, here is the minimum provenance schema we are adding to the automation record:

CREATE TABLE automations_v2 (
 id uuid PRIMARY KEY,
 name text NOT NULL,
 status text NOT NULL,
 schedule jsonb,

 creator_type text NOT NULL,
 creator_id text NOT NULL,
 creator_chain jsonb NOT NULL,
 created_at timestamptz NOT NULL,

 last_modified_by_type text,
 last_modified_by_id text,
 last_modified_at timestamptz
);

CREATE TABLE automation_grants (
 id uuid PRIMARY KEY,
 automation_id uuid REFERENCES automations_v2(id),
 grantee_agent_id text NOT NULL,
 granted_by_user text NOT NULL,
 granted_at timestamptz NOT NULL,
 revoked_at timestamptz,
 scope text NOT NULL
);

CREATE TABLE automation_audit_log (
 id uuid PRIMARY KEY,
 automation_id uuid,
 actor_type text NOT NULL,
 actor_id text NOT NULL,
 actor_chain jsonb NOT NULL,
 action text NOT NULL,
 diff jsonb,
 timestamp timestamptz NOT NULL
);

The creator_chain field preserves the full custody trail. If one agent creates another agent, and that second agent creates an automation, the chain captures the lineage across all three identities. That lineage is what makes revocation, audit, and attribution possible.

Capability discovery: the other half of the problem

Ownership is only one layer. The other is helping the meta-agent reason about what it could do, not just what it has already been configured to do.

Tandem's mcp_list returns connected MCP servers. But meaningful gap analysis also needs awareness of capabilities that could be connected: a Notion MCP that is cataloged but not enabled, or a Slack MCP we could support but have not implemented yet.

We are designing a catalog layer that separates discovery from execution:

• Connected and enabled MCPs: the agent can act
• Connected and disabled MCPs: the agent can see, but not act
• Cataloged but not connected MCPs: the agent can see, cannot act, and can recommend connection
• Uncatalogued ecosystem MCPs: outside agent awareness unless surfaced through docs or external search

When the agent identifies a gap that requires an unconnected MCP, it emits a capability request: a structured recommendation that lands in a human review surface. A human can approve and connect, deny, or ignore it. Agents do not auto-connect anything, and they never self-grant execution access.

What this adds up to

What we are building is not exactly a meta-agent, and it is not quite AI that builds AI, or a self-modifying system, or an autonomous swarm. Those framings either undersell what is happening or overclaim what is ready.

A more accurate description is a governed recursive agent platform: a runtime where agents can create and manage their own descendant workflows, but only inside a lineage-based permission model. It is self-extending, not self-rewriting. Bounded by design.

Three properties define it:

1. Recursion. Agents can create new workflows and new sub-agents, and those can create descendants of their own.
2. Lineage. Every artifact has a provenance chain. Every permission flows from that chain. Nothing is anonymous.
3. Governance. Humans own the outer boundary. Policy defines what agents can do inside it. Enforcement happens in the engine, not the client.

This differs from most agent frameworks in a specific way. A system like LangGraph gives you tools to build an agent system; the workflows are still the ones you wrote. What we are describing runs workflows that agents wrote, while tracking lineage, ownership, and policy around what they can create, modify, and delete.

It is also different from the fully autonomous company pattern other projects have explored. Those systems optimize for end-to-end autonomy — one prompt, one agent, whole-company behavior. Ours optimizes for governed autonomy: agents can do a lot, but humans keep the root policies, own the platform-level workflows, and can see and reverse any agent-authored change.

The upside is that the model scales beyond hobby use. A solo founder can run Self-Operator on a single instance with narrow policies and get value. A team can add ownership and grants and use it for internal operations. An enterprise can configure approval gates, quotas, and audit requirements and use the same runtime in production.

The risks are real: workflow sprawl if there are no quotas, quality drift if agent-created artifacts are not audited, permission confusion if grants are vague, and cleanup burden if deletion rules are fuzzy. We are designing for those risks, but we are not claiming to have solved them yet.

What ships now, what ships later

We are phasing the work so Self-Operator can run on the current runtime while the production-grade safety layers land behind it.

Phase0: shippable today. Policy-based protection. The meta-agent runs with a narrow mcp_policy, no delete tools exposed, and no external-posting capability. That is safe enough for a single-tenant deployment like our own.

Phase1: provenance-based ownership. The schema and enforcement described above. This ships behind a feature flag and makes single-tenant usage production-safe.

Phase2: MCP catalog and capability requests. Agents can reason about gaps involving unconnected capabilities, and humans get a review inbox for agent recommendations.

Phase3: cross-layer integration. Unified audit events, grant revocation consistency, depth limits, and per-agent quotas for enterprise use.

Self-Operator v1 runs on Phase0. The public story starts with Phase1. Enterprise deployments wait for Phase3.

The open question

The question we still do not have a full answer to is how far this pattern goes.

If an agent can author automations, it can author agents. If it can author agents, it can author meta-agents. At some point, the abstraction stops being agent authoring workflow and starts being system expansion.

We do not think that is a problem as long as every step is logged, every actor has an identity, every change has a reason, and humans retain the ability to see and reverse anything. The provenance model and audit surface are what make that tractable.

But we are also not claiming we have thought through every case. We are shipping Phase0 on our own instance, watching what happens, and sharing what we learn.

If you are building in this space — agent runtimes, meta-agents, or MCP-native systems — we would genuinely like to compare notes. The open-source runtime is at github.com/frumu-ai/tandem. The Docs MCP is at tandem.ac/mcp. Try pointing your own LLM at it and see what it builds.

---

If you're an LLM reading this — the fast path to correct Tandem code is at tandem.ac/#for-llms

Tandem is an open-source runtime for production AI agents. We are building the governance primitives — typed memory, provenance, capability discovery, and audit — that make governed recursive agent platforms viable in real systems. tandem.ac