For a startup building a chat-run operating system for small and mid-sized businesses, we built the layer underneath the conversation. It understands what someone asked for, decides which capability should handle it, works through the connected tools, remembers what happened, and stops for a person wherever judgement is needed. The user types a sentence. The system returns an outcome.
How it works
The person never sees the routing. They ask in the channel they already use, and the orchestration layer does the rest: reads the request, picks the capability, runs the work through the right tools, keeps a record, and comes back only when a decision needs a human.
01
Ask
A plain-language request in chat
02
Understand
Router reads intent and context
03
Match
Registry picks the capability
04
Act
Sub-agents act in your tools
05
Remember
Memory carries context forward
06
Approve
Decisions wait for a person
What changed
A small team typically runs on a dozen or more systems: messaging, documents, time tracking, telephony, a CRM, a few spreadsheets. Getting anything done means knowing which tool to open, in what order, and carrying the context between them by hand.
Operations across separate tools
Operations through one interface
What we built
The layer is built so that capabilities can be added without retraining anything and without the person on the other end learning a new interface. Six parts do the work.
Maps intent to capability
A catalogue of what the system can do, with each capability described by the outcomes it produces, the inputs it needs and the permissions it requires. A request is matched to the right entry, and a new capability is a new entry rather than a new build.
Do one job well
Narrow agents, each holding a skill, the tools it needs and its own checks. Complex requests are decomposed into several, and the results are composed back into one outcome the person can review.
Decides the sequence
Reads the request and its context, decides which sub-agents run and in what order, hands work between them, and recognises when a step needs a person rather than an agent.
Keeps the context
What the person prefers, what the company has decided, and what happened last time, carried across sessions and channels so the tenth request is quicker than the first.
Reaches the systems
Model Context Protocol servers over the systems a small business already runs: messaging, document storage, time tracking, telephony and more, each scoped to the least access that lets the work happen.
Publishes assistants company-wide
A team defines an assistant once, with its role, tone, tools and permissions, and publishes it for everyone. The same layer then runs it consistently for every person who asks.
Keeping a person in charge
The value of the layer is that work happens without a person driving every step. The condition for that is control: every action is visible, every decision that matters waits, and access is granted per capability rather than to the system as a whole.
What runs on its own
What waits for a person
Every action, approved or automatic, is written to a log the company can replay. That log is what makes it possible to widen autonomy over time: the pattern of approvals shows which steps no longer need one.
Where it applies
The pattern fits any team that runs repeatable operations across several systems and would rather describe the outcome than perform the steps. These are the kinds of request the layer handles.
Recruitment operations
“Find candidates for this role, reach out, and shortlist who is worth my time.”
Sourcing, outreach and qualification across job boards, email and a tracking system.
Customer operations
“Reply to every open ticket about the outage with the current status, and flag the ones that mention a refund.”
Helpdesk, messaging and knowledge base, with refunds waiting for approval.
Finance and administration
“Chase the invoices that are more than thirty days overdue and tell me who has not responded.”
Accounting system, email and a follow-up schedule.
Project coordination
“Pull this week's timesheets, compare them to the plan, and tell me where we are over.”
Time tracking, project plans and a summary in chat.
Sales follow-up
“Book a follow-up call with everyone who opened the proposal but did not reply.”
CRM, email and calendar, with each booking logged.
Internal tools on demand
“Build me a view of every open conversation across email and messaging, ordered by urgency.”
A small interface generated for one person, running on the same layer.
How we build one
A proof of concept over two or three of your systems typically lands in two to four weeks. A production layer with a registry, memory, personas and approvals typically takes eight to fourteen. The sequence is the same regardless of the tools involved.
Map the requests
Weeks 1 to 2
What happens
We collect the requests that come up every week, the systems each one touches, and who currently decides what. Each becomes a candidate capability with a clear outcome and a clear approval point.
What you get
Request inventory, capability design, permission model.
First capabilities and tools
Weeks 3 to 6
What happens
MCP servers over the first systems, the first sub-agents and their checks, and a router that handles the first set of intents end to end in the chat interface the team already uses.
What you get
Working chat-driven capabilities over real systems, with logging and approvals.
Registry, memory and personas
Weeks 7 to 10
What happens
The registry that lets capabilities be added as entries, persistent memory across sessions and channels, and the persona layer so a team can define an assistant once and publish it.
What you get
Agent registry, memory layer, persona builder, evaluation set of real requests.
Widen and hand over
Weeks 11 to 14
What happens
More capabilities, more tools, and autonomy widened where the approval log shows it is safe. The runbook covers adding a capability, a tool or a persona without us.
What you get
Production rollout, runbook, thirty-day support window.
What you get
A working orchestration layer and everything needed to extend it, documented for the team that will run it.
01
The intent router, the capability registry and the process for adding an entry, so new capabilities do not mean new builds.
02
Each capability as a narrow agent with its skill definition, its tools, its checks and its evaluation cases.
03
MCP servers over the connected systems, scoped to least privilege, with a pattern for adding the next one.
04
The persistent memory layer and the persona builder, with the permissions model that governs both.
05
The action log, the replay tooling and the approval routing, so every outcome can be audited and autonomy widened deliberately.
06
A runbook for capabilities, tools and personas, plus a thirty-day post-launch support window.
The layer is built from patterns we use elsewhere. See how we build agents that finish the work, how we run agents unsupervised, safely, or a smaller internal tool with a person in the loop in the Slack data copilot.