H6 Orchestra: multi-agent systems with roles, contracts and per client isolation

Companies already use artificial intelligence. What almost none of them have is a way to organize it once it stops being a tool and becomes several artificial coworkers operating on the same business.

With one agent, good instructions are enough. With twenty, working for several clients at once, failures appear that make no noise: they look correct until it is too late.

There are three of them, and all three share something uncomfortable: none returns an error.

• Rules that contradict each other: the same instructions copied in several places, each copy a different version. The agent applies whichever one it happened to read.
• Work that depends on memory: every session rebuilds where things stood, and nobody can audit afterwards what each agent did.
• One client data inside another client work: a credential that sees many accounts and an agent choosing by name. The platform answers without error, with the wrong data.

A report containing another company analytics looks exactly like a correct one. That is the problem Orchestra exists to solve.

Orchestra is not a tool you install: it is a complete method. The team, the rules that govern it, the controls that enforce them and the consulting work to install it in a real operation.

It rests on an idea that runs through the whole system: every piece has one shape and exactly one meaning, and that is what lets you read a team of agents the way you read a blueprint. Agent, work, contract, gate, client, state, log and flow. Eight shapes, eight meanings, no synonyms.

A roster of roles, not a chatbot

• Every role has its own doctrine, written boundaries and a single owner per decision.
• Direction takes requests and distributes work, but does not execute another role tasks or repair the machine.
• Orchestration maintains the machine: each agent identity, the launcher, the controls and the isolation. It does not decide on anyone else work.
• Knowledge guards the format and the doctrine, and guarantees that each rule lives in exactly one place.
• QA independently verifies what another agent claims to have done: whoever builds is not whoever approves.
• And across each client channels work the roles for SEO, paid media, website, CRM, sales, BI, development and quality, replicable per client, brand or market.

Each agent contract: seven blocks, always in the same order

• Identity: who it is, what role it fills and why it exists.
• Actionable state: the only place where what needs doing lives, and it wins against any contradiction.
• Startup: what to read when beginning, in what order and with a maximum reading budget.
• Log: where what happened gets recorded. It is history, not state.
• Foreign: what does not belong to it, with the exact permission for each item.
• Policy: pointers to the rules that open depending on the task. Never copies.
• Action limits: what requires explicit human approval before running.

If one is missing, the verifier flags it red.

Capped context, because depth cannot come at a price

• Context loads cumulatively, so a startup file that grows without limit makes every session begin by reading rules that are not its own.
• And an agent carrying someone else policy in context applies it.
• That is why each level has a hard cap: 40 lines for the organization root, which is only the map and zero policy; 60 lines for the area; 150 lines for the working front.
• The detail lives separately, in units that open only when the task calls for them.

Five isolation controls, all of them before access

• One session, one client: each session belongs to a single client and its name says so. There are never two clients in the same context.
• A gate before every access: the agent opens its client gate, and if it does not match, it stops. The rejection happens before calling the platform, not after.
• Identifiers that are never typed: no property, account or site is typed or recalled. It comes from the client record, because an agent memory is not a source.
• Credentials out of reach: they live outside the projects and are read only through their module. No agent writes them, copies them or leaves them in history.
• Only the resources it needs: the gate hands over exactly that and nothing more.

Rigor: what is declared gets verified

• A control that does not measure looks identical to one that does, so every important rule has an automatic verification.
• And every verification is tested by breaking what it watches: before trusting a control it is run where we already know a problem exists, and if it stays green, it does not measure.
• Tools fail instead of warning, because a visible error gets fixed and one that looks correct multiplies.
• And there is a catalog of more than twenty concrete ways a verification reports something different from what it measures, each trap with the real case that uncovered it and the rule that closes it.

The conclusion that unites them is uncomfortable and useful: none failed for not measuring. They failed measuring what did not decide.

Seven phases to install it

• Diagnosis: a map of the operation and its risks.
• Roster design: which roles, with which boundaries and who invokes whom.
• Policy: context format, contracts, protocols and action limits.
• Isolation and credentials: each client record and its gates, verified.
• Deployment: every front declared, with its own identity, state and log.
• Verification: the suites installed and tested by breaking what they watch.
• Operation and continuous improvement: training the team to open, distribute and close sessions, read logs and audit.

It is the same path we walked to restructure our own operation. Learn more about AI agents and software development.

Hábito 1 built Orchestra to turn a set of loose agents into a team that can be directed, audited and grown.

What gets installed

• A roster of roles with their own doctrine and a single owner per decision, replicable per client, brand or market.
• 7 block contracts per agent, with context caps of 40, 60 and 150 lines by level.
• 5 isolation controls acting before every access.
• A catalog of more than 20 measurement traps documented with their real case.
• 7 implementation phases, each with a verified deliverable.
• A complete body of policy: seven block contracts, protocols, exit codes and more than a dozen documents.
• Five isolation controls that reject the operation before touching the platform.
• Verification suites that were tested by breaking what they watch.
• A catalog of more than twenty measurement traps, each with the real case that uncovered it.

What changes in the operation

• The state of the work stops living in a session memory and moves somewhere auditable.
• Each rule lives in exactly one place, so two versions of the same instruction stop existing.
• Isolation between clients stops being an intention written in a prompt and becomes a control that stops the work.

Why it matters

• The difference between a team of agents and twenty loose agents is not the count: it is whether anyone can answer what each one did and with whose data.
• And that answer does not come from better instructions. It comes from contracts, gates and verifications that fail loudly.