Nine operational practices to keep your team of agents from becoming the sorcerer's apprentice's broom.
In 1797 Goethe published a short ballad called Der Zauberlehrling, the sorcerer's apprentice. The master steps away. The apprentice does not want to carry buckets of water, so he teaches a broom to do it for him. The broom obeys. The broom obeys too well. The workshop ends up flooded. In 2026, the AI agent industry lives that same scene every day, in different offices and with different brands of broom.
This text is not a critique of the models. Today's models are perfectly capable. It is an honest description of the nine practices we have adopted at Centrum Transgenia to operate a team of twelve internal agents, without shutting it down every week, without flooding the workshop.
A warning before we begin. In this text you will find no rounded revenue figures, no ROI percentages, no client names. The reason lies in practice number eight: zero fabrication. Only verifiable mechanisms.
The problem. Brooms that obey too well
Agent teams fail when they move from the demo to operation for reasons that repeat across every industry. They do not fail from model weakness. They fail from an excess of capability without governance.
A brief catalogue, sober, without ornament:
- Autonomy without traceability. An agent executes an action; no one can reconstruct why.
- Confident hallucination. The model produces a nonexistent fact with the same cadence with which it produces a correct one.
- Mute memory. Each session begins from zero. Tuesday's lesson is lost by Thursday.
- Fragile governance. The rules live in the prompt; the next regeneration erases them.
- Opaque cost. No one knows which agent consumed how much. The bill arrives at the end of the month.
- Borrowed identity. Two agents speak as one; the telemetry cannot tell them apart.
- The tool inherited by accident. An agent acquires permissions that are not its own.
- Writing without a frontier. There is no structural difference between proposing and executing.
Any decision-maker with a working demo in hand can skip this catalogue. Any decision-maker with two months of real operation reads it patiently, because they recognize the scenes.
The thesis. A card that fits in your pocket
After twelve months of operation, the thesis reduces to four verbs with mandatory subjects:
The AI proposes. The human approves. The system records. The company learns.
It is not a recommendation. It is a hierarchy. Each verb has its own subject and they are not interchangeable.
An agent can produce a draft email, an accounting entry, a press pitch, an entire article. It cannot send the email, post the accounting entry, send the pitch, or publish the article without a human approval phrase in an exact format. The system, meanwhile, stores the draft, the prompt, the source, the model, the timestamp, and the signature. The company closes the loop by consulting that record when the next analogous decision appears.
The word that sums it all up is draft-first. Every agent delivers a draft first. No agent publishes without permission. It costs friction; it pays in auditable operation.
Nine practices that are uncommon in the industry
I present them all with the same structure: what it is, why it is uncommon, how to replicate it on your team. None depends on our stack; all can be built on open projects.
1. Governance at the write frontier, not at capability
What it is. We do not limit what the agent can read. We limit what it can write. An agent can query the ERP, email, the CFDIs, the dashboards, even converse with other agents. No agent can modify an operational record, send an email, cancel an invoice, or publish an article without crossing a triple lock: environment flag, runtime confirmation, human approval phrase in a fixed format.
Why it is uncommon. The demo looks better the more autonomy it shows. A write lock reduces the number of tasks an agent closes without intervention, and that reads as weakness in a platform pitch. In operation it is the difference between trusting it with the CRM or not.
How to replicate it. Split your tools into two explicit lists, read_tools and write_tools. Expose the second only with WRITES_ENABLED=true. Log every failed attempt; they serve to discover new failure modes.
2. Multi-vendor trust tiers
What it is. No operational decision depends on a single model provider. We distribute the work among several according to the level of trust the task demands. The internal mnemonic is affectionate: Mistral proposes, OpenAI produces, Claude disposes. An economical model drafts, an intermediate one refines, one with greater reasoning reviews.
Why it is uncommon. Lock-in is comfortable. A single SDK, a single billing panel, a single contract. The bill comes due when the price changes, the usage policy changes, or the region goes down.
How to replicate it. Define three tiers in your router (draft, refine, dispose) and assign each task by reversibility and cost. Document the per-tier allowlists in a versioned file. Reassess every quarter.
3. Observability by design
What it is. There is no execution that leaves no trace. Prometheus for metrics, Grafana for panels, Langfuse for traces and sessions, OpenTelemetry as the unified emission layer. On top, a panel of our own that makes the delegation between agents legible: who called whom, with which skill, which droid it activated, which memory it consulted, when it closed the session.
If it isn't visible, it isn't trusted.
Why it is uncommon. The initial instrumentation is perceived as cost before it yields value. Observability's technical debt grows silently until an incident makes it visible; by then it is structural.
How to replicate it. Emit service.name, gen_ai.agent.name, gen_ai.model, gen_ai.tokens.input, gen_ai.tokens.output, gen_ai.tool.name on every inference. Build the delegation panel from day one.
4. Audit as a contract, adversarial review between agents
What it is. Each intervention closes with a folder bearing an ISO date and a fix_log.md: sources, decision, state before and after, human signature. On top, a second agent, of a different role, runs an adversarial review and publishes its security_review.md alongside the fix_log.
No audit, not delivered.
Why it is uncommon. In a production model centered on speed, review between agents is perceived as a bottleneck. In a model centered on trust it is the only way to detect systematic error patterns.
How to replicate it. Folder convention audit/<YYYY-MM-DD>/<slug>/. Mandatory fix_log. A second reviewing agent with a role distinct from the first.
5. Durable guardrails that survive auto-heal
What it is. The critical rules live outside the regenerable block. We load the core from versioned files (BRAIN.md, a per-agent local CLAUDE.md) that a periodic heal re-applies across the twelve agents.
Why it is uncommon. Teams that operate with configuration GUIs confuse the visible state with the durable state. The first regeneration erases the rules and they discover, too late, that they need a source of truth outside the vendor's container.
How to replicate it. Identify rules that can never be lost, move them to versioned files outside the vendor, write a daily reconciliation script.
6. Read-first phase and a declared "nature" per exercise
What it is. Every capability is born read-only. The commercial intelligence was born reading the CRM. The PR intelligence was born reading authorized channels. Writing is enabled afterward, once the reader has demonstrated stability. In addition, each task declares its "nature" before touching anything: audit-only, protected-state-safe, remediation-with-VoBo, content-drafting-no-publish.
Why it is uncommon. Commercial pressure pushes to show value as soon as possible. The read-only phase produces no visible deliverables. Teams that skip it discover, too late, that they granted write permissions before knowing the failure modes.
How to replicate it. Default READ_ONLY=true for every new capability. A minimum of two weeks of reading operation before enabling any write. A closed taxonomy of exercise natures.
7. Isolated identity per agent
What it is. Each agent with its own projectPath, its local CLAUDE.md, its distinct service.name, its unique slug in memory. The operational core is shared by hardlinks or junctions, not by copy. It solves three problems at once: persona collision, telemetry attribution, memory contamination.
Why it is uncommon. SaaS platforms optimize for "a single panel" and treat the team as a list inside a container. Telemetry and memory end up attributed to a collective identifier.
How to replicate it. A root folder per agent. A local CLAUDE.md that declares name, role, gates, and voice. OTEL_SERVICE_NAME with the pattern equipo-<slug>. Operational core shared by hardlink.
8. First-class anti-fabrication with a source hierarchy
What it is. If the agent cannot verify a fact, it declares it unknown. No approximations, no rounded figures that sound credible. In addition, each domain has its hierarchy of sources of truth, closed and written:
- In SEO, Google is the primary authority (Search Console, URL Inspection). Other tools are support.
- In accounting, the order is SAT (l10n_mx_edi_cfdi_sat_state), CFDI vault, bank statement, Odoo record.
Why it is uncommon. Generative models, by design, prefer to complete a plausible text rather than leave a visible gap. Holding the policy requires repeating it in every system prompt and accepting incomplete deliverables as preferable to invented ones.
How to replicate it. Write the literal policy into the system prompt: "if it cannot be verified, it is declared unknown". Publish the source hierarchy by domain. Treat an invented figure as a serious incident.
9. Shared capability pool, inheritance by design
What it is. Each capability is developed once, in two formats: a skill (documents and operates) and a droid (executes with its own context). Both live in a single pool that every agent can invoke. Three compositional droids (session-guard, vobo-gate, audit-logger) activate as the preflight and post-flight of every sensitive execution.
Write once, every agent inherits.
Why it is uncommon. Most platforms force you to duplicate the capability in each agent. Every duplication is a future divergence.
How to replicate it. A single directory of capabilities. Hardlinks or junctions to each agent. Compositional guardrails activated by convention on every execution that touches an external system.
Playbook, eight steps for the team that starts tomorrow
- Declare the trades. Forbid "general purpose".
- Split the tools by role and by read/write.
- Instrument with OpenTelemetry from day one.
- Write the anti-fabrication policy with a source hierarchy.
- Establish the approval gate with an exact phrase.
- Create the audit convention with a folder per date and adversarial review.
- Move the guardrails out of the vendor's config blob.
- Introduce a multi-vendor router with tiers.
Each step can be built on open projects: Prometheus, Grafana OSS, Langfuse, OpenTelemetry, Qdrant, MCP. There is no need to sign a closed-platform contract to begin.
From apprentice to master
In Goethe's ballad the apprentice is saved only when the master returns. The master does not arrive shouting; he arrives with a short phrase that breaks the spell. Then he sets things in order. Then he records. Then he teaches, so that the broom does not flood the workshop again.
At Centrum Transgenia we decided that this master is not a magician. It is a protocol. The short phrase is an approval gate. The order is a fix_log. The record is a dated folder. The teaching is a BRAIN.md.
No one arrives in an emergency. Nothing floods. The broom works. The apprentice learns. The workshop stays open the next day.
If your company is considering building a team of agents, or already has one and finds that the broom has overflowed, write to us. The conversation begins at [email protected]. We bring the protocol. You bring the workshop.
The complete whitepaper (appendices, glossary, source hierarchy by domain, and CC BY-SA license) is available on request by writing to [email protected].