Internal operations
Works the queue of manual tasks your ops team handles in an internal admin, calling your own API endpoints to do each step.
Not every business runs on a platform. If your work lives in your own application, APIs and databases, we build the agent against those directly, through MCP servers that expose exactly the operations its task needs and nothing more.
01Use
Each one is scoped to a single job and reaches your systems through tools we write against your API, not through broad database access.
Works the queue of manual tasks your ops team handles in an internal admin, calling your own API endpoints to do each step.
Answers customer and account questions from your data and docs, with read-only access to a replica or reporting database.
Pulls figures from your systems on a schedule, checks them against rules you define, and writes a report or raises an alert.
02Wire
Five surfaces, defined by you. We write the contract between the agent and your systems, and the agent can do nothing that contract does not name.
Read access is broad enough to answer the question, write access is narrow, and every write has a gate until you decide otherwise.
| Agent | Reads | Writes | Human gate |
|---|---|---|---|
| Internal operations | Your API reads | Your API endpoints named in the contract | Every write, until widened |
| Support and account questions | Read replica, docs | Drafted replies | Anything sent to a customer |
| Data and reporting | Warehouse or database reads | Reports, alerts | Alerts sent outside your team |
03Gate
There is no platform admin to borrow, so the approval step goes where your team already works: your internal tool, or a small queue we add to it.
In your own internal tool or admin, as a queue of held actions, with the same login and permissions as the rest of it.
The call the agent wants to make, with its inputs, the record it targets, and the run trace behind it.
Every write to your systems, until you widen the agent's authority endpoint by endpoint, and anything sent to a customer.
The run stops, the rejection is kept with its trace, and it becomes an eval case the agent is tested against on every change.
04Asked
No. We prefer your API, because it already enforces your rules. Where the agent needs to read data the API does not expose, we ask for a read replica or a reporting database.
The agent talks to your systems over HTTP or through an MCP server we build, so your application can be written in anything. The MCP server is written to fit your stack and handed over with the code.
You do, on full payment, as set out in the terms. The code, prompts, tool definitions and eval cases live in your repository.
Tell us the task your team does by hand in your internal tools. We will tell you which endpoints the agent would need, where the gate sits, and what the MCP server would expose.