Integrate
Connect your agent to the system where the work actually happens
A first project with a narrow shape: one existing agent or workflow, connected to one business system, with acceptance tests and a handover. Small enough to scope in writing and finish.
Good starting points
- Your agent or chatbot answers well, but someone still copies its results into the CRM by hand.
- A voice or chat agent needs to look something up or write a record in your system during the conversation.
- You have an automation in Make, n8n, or Zapier that needs a custom step those tools can’t do.
- Your team uses Claude or ChatGPT and you want it to work with your own data through an MCP server.
- An existing integration works on a good day but creates duplicates or drops events on a bad one.
What the first milestone delivers
- The integration itself
- Code that reads from or writes to the agreed system, running in your accounts.
- Duplicate and failure handling
- The same event arriving twice is handled once. Failed calls are retried within limits, then reported, not lost.
- A log you can read
- Each action records what came in, what was done, and whether it worked.
- Acceptance tests
- The cases we agreed in the scope, including failure cases, run against your test data.
- Handover
- Setup notes, how to run the tests, and a walkthrough for whoever maintains it.
What we need from you
- Access to a test or sandbox account for the system, or a safe subset of production.
- API documentation, or permission to use the vendor’s public API.
- A few real examples of the inputs, with personal data removed.
- One person who can answer questions and confirm the acceptance tests.
What’s not included
- Building a new agent from scratch. That is a Build project.
- More than one target system in the first milestone.
- Getting around a platform’s API limits or terms of service.
- Vendor, API, and hosting fees. Those stay on your own accounts.
- Open-ended support. What is included after delivery is written into the scope.
How scope and price are agreed
You send a brief
The agent or workflow you have, the system it should connect to, and what should happen.
We reply with questions or a scope
The scope lists deliverables, exclusions, acceptance tests, milestones, and a fixed price. Nothing starts until you agree to it in writing.
We build against your test data
You see it working in your own system before the final milestone is due.
We hand it over
With documentation, tests, and the support terms from the scope.
What we’ve built that’s like this
We have not yet delivered an integration for a paying client, and we’d rather say so. What we can show is the same kind of work in our own systems:
KOTA connects a live phone conversation to a Postgres database and to SMS through typed tool calls, and only tells the caller a text was sent when the messaging API confirms it.
The outreach pipeline refuses duplicate sends and enforces a daily limit in the send step itself.
ARCHON connects MCP servers and asks a person before running risky commands.
Start with a brief
A few lines about the agent you have and the system it should connect to. You’ll get back questions or a proposed scope.