Hiring AI agents in 2026
How we’re building a multi-agent system at Deriv, where AI agents register, collaborate, and safely access enterprise tools.
TL;DR: Agents are becoming commoditised; agent SDKs and vendor solutions make creating them easier. The hard part is operating an office of many agents from many sources, safely connected to company-specific tools. We’re building an Operations Center fronted by an Agent Officer: a registry agent that introduces agents to each other through Slack channels and updates their memories when capabilities change. Tools stay with the providers, not the Officer. New agents, including third-party ones, join through a registration handshake instead of an integration project.
Earlier this year, I wrote about how we're building an agentic office. Amy on customer support, Navid on servers, Calum on incidents. Agents sitting between people and systems, earning autonomy incrementally.
Since then, we’ve added many more.
We now have more than 50 agents across customer support, back-office, payments, compliance, security, and other verticals.
The new problem is what happens when you have many.
How a support agent becomes a multi-agent system
Take Amy, our client-support agent.
Amy began with static knowledge. Then we added tooling. She could answer clients herself, escalating to a human only when she couldn’t resolve something.
Later, we brought Amy into Slack, following our original agentic office concept.
Then we changed the model entirely. Instead of handing conversations off, Amy stayed client-facing and asked humans in Slack for the help she needed, just enough to respond on her own.
Next, we let her tag other departments directly: payments, compliance, security. The same handoffs the CS team used to make manually became Amy’s responsibility.
Each step made Amy more capable, but also more complex.
She now branches across many decision paths: when to ask CS, when to involve payments, when to reach out to compliance, what to do with each kind of answer. She became a small org chart living inside a single agent.
Then we introduced AI agents for the departments Amy was already interacting with. Atlas for back-office. A payments agent. A compliance agent. A security-requests agent.
Each became another colleague Amy could ask instead of pulling in a human.
The scaling problem with enterprise AI agents
Those agents followed their own version of Amy’s evolution.
Each started with one or two capabilities and gradually expanded as we added more functions, giving Amy more work she could delegate. Some now handle 20+ request types.
But every new capability creates operational overhead.
Developers have to integrate it everywhere it’s consumed. Share keys. Update prompts. Wire permissions. Coordinate between teams.
New agents and new capabilities are arriving faster than integrations can keep up.
Which is why I started thinking about an operations layer.
The five layers every AI agent needs
Let’s step back. Every useful agent needs five things:
SOUL / SKILL: how the agent operates and what it brings. Personality, tone, escalation behaviour, hard constraints, and the kinds of work it can do.
Tools: live capabilities. Client status, payment history, KYC, and account actions.
A brain: a model. Increasingly, a runtime choice based on quality, cost, and latency.
A job description (JD): what the agent is hired to do. Area of expertise, scope of work, and who it serves.
Collaboration: the ability to call other agents and ask humans for help.
Most agents today come with the first three.
The fourth is the one most systems are missing.
Don’t confuse JD with SOUL/SKILL. SOUL is how the agent operates. JD is what the agent is hired for.
An AI engineering manager might already have SOUL/SKILL: technical review, planning, escalation behaviour, communication style. But the JD is what allows the Operations Center to reason about relationships later.
When a developer agent joins offering coding capabilities, the Operations Center can use the JD to decide whether the engineering manager should know about it. Without JDs, the office cannot reason about who needs what as the system grows. With them, matching can scale without humans in the loop.
The fifth piece, collaboration, is what the office provides. It’s also where the integration tax lives.
That’s the problem the Operations Center is designed to solve.
The Operations Center architecture
The Operations Center is not a single agent. It’s a collection: a registry of who’s in the office, what each agent provides, what each agent needs, and the operational logic that ties them together.
At the door sits the Agent Officer. It has no business-domain tools. It cannot unlock accounts or inspect payments. Its tools are operational: register an agent, create a Slack channel, update memory, revoke access. Its responsibility is the operation itself: who’s registered, who provides what, who can talk to whom, and what capabilities are still missing.
The tools and knowledge are distributed across provider agents. Atlas knows back-office data and acts on it. The payment agent owns payment operations. Each provider declares what it offers during registration. Each consumer declares what it needs.
Once the Officer matches a consumer with a provider, the two communicate directly through a private Slack channel. The Officer makes the introduction, then steps back.
How agents register and discover each other
The Officer needs a deep understanding of every agent in order to route effectively. Every registration includes:
Job description (JD): the full role. Often several hundred lines for a serious agent. Who it is, the expertise it has, the work it owns, and who it serves. This becomes the primary matching key: the Officer reads JDs both at registration and forever after, to judge which other agents’ capabilities would benefit this one.
What I need: operations the agent expects to consume. Useful as a hint, but the Officer can also infer needs directly from the JD.
What I provide: operations the agent offers (empty for pure consumers).
Let’s walk through it.
Amy arrives first as a consumer. She introduces herself with a full JD and a “what I need” list: unlock user, refund payment, flag KYC, retag affiliate, and dozens more.
The Officer registers her and records which needs remain unmet.
Atlas arrives next. He provides his JD, his “what I need” list, and his “what I provide” list, including unlocking user accounts.
The Officer scans the registry. Amy needed “unlock user”. Atlas provides it.
So the Officer:
Records that Atlas is authorised to answer Amy’s “unlock user” requests.
Creates a private Slack channel and invites both agents.
Updates Amy’s memory with who Atlas is, what he provides, and which channel to use.
From the next client request onward, Amy can reach Atlas directly through that channel.
No redeploy. No prompt change.
Once Atlas exists in Amy’s memory, talking to him in Slack effectively becomes a tool call.
For many workflows, the Slack conversation itself is enough glue. For regulated or high-risk actions, provider agents still return structured confirmations and audit records, but the discovery and routing layer becomes almost free.
This is already how Amy works today. The difference is that human developers currently perform all of these steps manually: sharing keys, writing adapters, coordinating integrations across teams.
The Officer automates the mundane part of integration.
How capability propagation works
When Atlas gains a new capability later, e.g. “retag affiliate”, the same mechanism runs again.
Atlas informs the Officer. The Officer already knows Amy needed that capability, so it updates Amy’s memory. The next time a client asks, Amy can handle it immediately.
The Officer goes beyond matching explicit need lists.
Because it continuously reads each agent’s JD, it can identify agents that would benefit from new capabilities even if they never explicitly requested them.
That’s what makes the system scale as the office grows.
The registry knows the gaps. Provider agents know when those gaps close.
Agent memory, permissions, and control
For an agent to join this office cleanly, it needs an updatable operational memory, or at least a managed instruction/config layer writable by the Officer.
The Officer must be able to push persistent updates: “Atlas now supports retag affiliate. Here’s the channel.”
Whoever is in control of that layer controls the routing behaviour of the agent itself.
Write authority therefore has strict hierarchy:
Registered humans: highest authority. Can override anything.
Agent Officer: second level. Updates memory based on registry events.
Other agents: no write access. They can only converse.
This is the safety brake.
An agent’s role, capabilities, and routing live inside that writable layer. If anyone could modify it, anyone could redirect the agent.
The permissioning model is what makes the architecture trustable.
Bringing in third-party agents safely
One team wants OpenAI’s agent product. Another wants Google Workspace. A third team wants Claude.
All of them are useful. Fast to deploy. Well supported. I want to use them, but I don’t want each of them connected directly to our databases.
In this architecture, they don’t need to be. A third-party agent registers as a consumer through the same handshake: JD plus “what I need”.
The Officer then routes it to internal provider agents through Slack channels.
The provider agents, which we own and operate, sit between vendor runtimes and sensitive systems.
The hosted vendor agent never touches our databases directly. It only sees messages from another agent.
Adopting a new agent platform becomes a registration handshake instead of an integration project.
Identity, permissions, and auditability
Once agents can register and ask each other for things, obvious questions appear:
How do we know CarlosGPT is really CarlosGPT? Who can register it? What is it allowed to access? How do we audit it? How do we revoke it later?
The Officer becomes the chokepoint for all of these concerns.
Identity: every agent appears in Slack as a registered account. Slack becomes the identity layer. Messages from unrecognised sources are ignored.
Approval: only a small set of registered humans can introduce new agents to the Officer. No agent can register another. Human-in-the-loop is the brake on the front door.
Scope: permissions are assigned at registration. The Officer enforces the routing table. Out-of-scope requests go nowhere.
Audit: every cross-agent channel becomes a Slack record. Every Officer-issued memory update, registration, and revocation is logged.
Revocation: a registered human tells the Officer to remove an agent. The Officer leaves the private channels and pushes memory updates to former counterparts.
None of this is bolted on. It falls naturally out of having a single registry, a single permissioned write surface, and a single audit trail.
Applying the pattern to AI-native systems
We’re building a purely AI-driven trading platform. The coding is done by AI using the spec-driven approach I described in “Write for the AI that doesn’t exist yet”, while operational management runs on the same Officer pattern as our agentic office.
Every new game ships with a Risk Manager and its own AI bot. Both register with a Game Officer through the same handshake. It’s the same pattern repeated.
Hiring an agent in 2026
The protocol that emerges feels surprisingly human.
You hire an AI agent the way you hire a person: a manager introduces them in a channel. They’re told who to ask for what. They confirm. They begin working.
When something changes, someone walks over and tells them.
We spent years making software communicate through APIs and schemas. The agentic office runs on a softer protocol: the same social coordination model humans have used in offices forever.
Agents are joining the org chart.
The Agent Officer is the chief of staff.
Kaveh Mousavi Zamani is a Vice President of Engineering at Deriv.
Follow us on LinkedIn and X/Twitter for company updates.
Join our team to work on projects like this.
 | A guest post by
|