We Run Our Own Agency on an Agent Mesh. Here Is the Live System.
Four AI agents, one per seat, each scoped to that role and governed by permissions the agent itself cannot change. The system we run our own agency on, including the parts that broke.
Most business AI is one shared assistant that everybody talks to and that can see everything. That is not a workforce, it is a single point of failure with a friendly interface.
One agent per seat, each in its own isolated container with its own credentials, permissions enforced on the host machine outside the agent's reach, and an approval gate on every outward action.
Four agents doing real recurring work, a governed control plane, and a published build log recording every failure along the way, including the six days the whole mesh was dead while every health check reported green.
What is an AI workforce, and how is it different from a chatbot?
An AI workforce is a set of agents, one paired to each seat in a company, that read real business data, do the recurring work of that role, and report back. Not one assistant everybody shares. A separate agent per seat, each holding only the access that seat should have.
The difference is permissions. A finance agent should see the bank feed; an operations agent should not. If every agent can see everything, you do not have an AI workforce - you have a data breach with a friendly interface.
Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% in 2025. Arriving fast is not the same as working: MIT's Project NANDA reviewed more than 300 disclosed AI initiatives and found 95% of generative AI pilots produced no measurable P&L impact, with mishandled deployment rather than weak models as the cause.
Why did we deploy it on ourselves before selling it?
Because we were not going to sell an AI workforce to anyone before running one in production with real consequences when it broke. Our own agency was the first deployment, and the failures were ours to absorb rather than a client's.
We kept a build log from day one that records the misdiagnoses and outages as carefully as the wins, because for anyone weighing this up the failures are the useful part.
A restriction that exists only as a sentence in a prompt is not a control. Test the behaviour, never the declaration.
How do you stop one agent from seeing another agent's data?
By enforcing permissions outside the thing being permissioned. Each agent runs in its own container under its own system identity, with its own credentials. Access rules live on the host machine, outside every container, where no agent can reach them. An agent can be argued with; a host-level rule cannot.
- One container and one system identity per agent. No agent's storage is mounted into another's.
- Credentials scoped per agent, so the operations agent physically cannot read what the HR agent holds.
- A control plane with row-level policies, reachable only through a scoped API - the agents cannot connect to the database at all.
- An approval gate on every outward action: client emails, payments, anything published.
The sensitive-seat rule matters most. Identity documents, banking details and payroll sit with one agent alone, and the others are structurally unable to reach them. Not by policy. By architecture.
What happens when it goes wrong?
It goes wrong, and the honest answer is that this is the part most case studies omit. For six days our entire subordinate mesh was dead while every control reported green. A model change had silently invalidated every scheduled job, and nothing was watching for absence - only for errors. Nothing errored, because nothing ran.
We also measured what our approval queue was actually made of and found the overwhelming majority were not judgement calls at all - they were permission bugs wearing a governance costume. Gating the wrong thing trains people to click yes without reading, which is worse than not gating at all.
We publish these because the alternative is a case study implying this was straightforward. It was not, and anyone telling you otherwise has either not run one in production or is not telling you what happened.
What do the agents actually do day to day?
Four agents hold four seats. They read live business data, do the recurring work of that role, produce digests on a schedule, and escalate on defined triggers rather than on judgement calls they are not qualified to make. They speak and listen in English and Malayalam.
The hard rule they all operate under is that no agent states a figure that did not come from a real query, and every figure names its source. If a lookup fails, the agent says so and stops. Confident fabrication is the failure mode that makes most business AI unusable, and it has to be designed against explicitly.
Can this work for a company that is not an agency?
Yes - the pattern is role-shaped, not industry-shaped. Any business with recurring per-role work and data spread across systems fits it. We deployed the same architecture for a jewellery and hospitality group, described in the Parakkat command centre build.
The productised version is our AI operating system service. If you would rather start with a single agent against one system, that is AI agent development. Talk to us.
Frequently asked questions
- How many agents does a company actually need?
- One per seat that has recurring, data-driven work - not one per person. We run four: founder, HR, operations and revenue. Most companies start with one or two where the repetitive load is heaviest, then add seats once the governance model has proven itself in production.
- What stops an AI agent from doing something it should not?
- Permissions enforced outside the agent. Access rules live on the host machine, beyond any container's reach, and every outward action drafts and waits for human approval. Instructions in a prompt are not controls - an agent can be talked around a sentence, never around a permission it does not hold.
- Can an agent see payroll or employee records?
- Only the HR agent, and only because that seat should. The others are structurally unable to reach that data - not restricted by policy, but isolated by architecture. Each agent runs in its own container with its own credentials, and no agent's storage is mounted into another's.
- Does this replace staff?
- It takes the recurring work off a seat, not the seat. The agents produce digests, run queries, draft, and escalate; a person decides. Every outward action still requires a human yes, so the model assumes people stay in the loop by design rather than by choice.
- How long before it is doing useful work?
- The first agent was doing real recurring work within days of arming, but reaching a governed four-agent mesh took roughly a month of daily iteration, most of it spent on permissions and failure handling rather than on the agents themselves. That ratio is normal and worth planning for.
Want a system like Neogen Media's shipped for you?
Book a 30-minute strategy call. We'll audit your stack, tell you what's leaking revenue, and sketch what a Neogen engagement would look like — no deck, no pressure.
A map of every manual task worth automating
Ballpark ROI on your top 3 automation opportunities
Honest read on whether we are a fit — or who is