Agent Architect
The Agent Architect is the builder's copilot. Describe the agent you want; it interviews you, drafts a valid Agent.md, validates it against the real pipeline, and checks the catalog so you reuse rather than duplicate.
At a glance
| Handle | @architect |
|---|---|
| Availability | Enabled on demand under Build → Capabilities |
| Model tier | advanced |
| Autonomy | supervised (the platform default — the definition declares none) |
| Tools | read_definition, write_definition, validate_definition, search_catalog |
| Routable | Excluded from delegation with the Orchestrator itself — it builds agents, it does not answer questions on their behalf |
How it works
-
It looks before it drafts
search_catalogsearches the agents you can already see. A near-duplicate is worth knowing about before you build a fifth agent that does the same thing — and near-duplicates are what make the Orchestrator's routing decision harder. -
It drafts into a buffer, never into the registry
write_definitionputs the draft in a per-conversation buffer and emits it as a draft card. Nothing is saved. Creating the agent is your act, in the designer or the Playground. -
It validates against the real pipeline
validate_definitionruns the same checks a save would — schema, slug uniqueness, skill references and their visibility, version pins, the model allowlist — and returns the same field-path errors. A draft it calls valid is one that will actually save.
It cannot create, publish or promote anything
Its four tools read, draft, validate and search. There is no write path to the
registry from this conversation, which is why it can be handed a rough idea
without any governance consequence.
It is a normal agent, so you can change it
Every built-in is an ordinary org-ring registry agent with a versioned
Agent.md. Edit it, publish a new version,
roll back — the platform only re-publishes its own definition when you have
not taken it over. See Build & promote.