Not a platform, and not broad AI consulting. Specific agents that do specific internal jobs, wired into the systems your team already works in, and handed over so your team can run them.
Most teams do not need a general assistant. They need the same six or seven internal jobs done reliably: routing a request, checking a record, compiling a summary, chasing a missing field, answering a question that is already documented somewhere.
Those jobs are narrow enough to automate well and boring enough that nobody wants to own them. They are where internal agents actually pay off — and where a generic chatbot deployment usually disappoints, because it was never pointed at a specific job.
Where internal agents tend to earn their keep first.
Reconcile records between systems, chase incomplete data, run recurring checks, and surface only the exceptions that need a person.
Research accounts before a call, enrich and route inbound leads, keep the CRM current, and draft follow-ups from what was actually discussed.
Triage and tag incoming tickets, pull the relevant history and docs, and draft a grounded first reply for a human to approve.
Read documents, extract fields, file them where they belong, and flag anything that does not match the expected shape.
Answer internal questions from your own documents with citations, so people stop interrupting the two colleagues who know everything.
Assemble the recurring report from source data, draft the commentary, and highlight what changed and why it might matter.
The same five steps every time, ending with your team owning it.
Watch how the work is done today, write it down, and decide which steps are rule-shaped enough for an agent and which need a person. Output is a ranked shortlist.
Build the top candidate against real data and run it beside the current process, so it is judged on real output rather than a demo.
Connect it properly: your systems of record, permissions, logging, evals, fallbacks, and an explicit human checkpoint wherever an error would be expensive.
Get the team using it, including what it is bad at. Adoption fails more often from unclear expectations than from model quality.
Documentation, runbook, and the ability for your team to change prompts, rules, and routing without calling me.
| Situation | Good fit for an agent? |
|---|---|
| Repeated many times a week, with a written or learnable rule | Yes — the classic case. |
| Needs reading unstructured text and pulling out structure | Yes — this is what models are genuinely good at. |
| Requires judgement but a draft saves most of the time | Yes, with a human approving the output. |
| Rare, high-stakes, and irreversible | No — or only as a checklist assistant to a person. |
| The underlying process is broken or undefined | No — fix or delete the process first. |
| Needs a guarantee of correctness every single time | No — use deterministic code for that part. |
These agents run against the tools you already pay for. The aim is that after handoff your team can maintain them, and that nothing depends on me staying involved.
The audit is deliberately a separate, smaller first step. It produces a ranked shortlist of what is worth automating and what is not, and you are free to stop there — sometimes the shortlist is the whole value, and the build can wait.
Scope and cost are quoted per engagement, since the work depends on how many systems are involved and how clean the process already is. I do not publish a rate card because it would be wrong for most of the jobs people bring me.
What I need to scope it: how the process runs today, which tools it touches, and one person who knows it well. Terms and handover are agreed in writing before anything starts.
Vendor features are built for the average customer and stop at the edge of that vendor’s product. Most internal work crosses several tools at once. Custom agents are worth it when the job spans systems, depends on your own rules, or needs data none of those vendors hold.
Usually not. Most internal agents read from the systems that already hold the data — a CRM, a ticketing tool, a shared drive, a database. A warehouse helps for reporting agents, but it is rarely a prerequisite for starting.
Scope permissions to the minimum the job needs, make risky actions require human approval, log every step, and write evals for known cases so regressions are caught. Read-only first, write access only where it has earned it.
That is normal and usually correct at the start. Running the agent alongside the existing process for a period, where people can see its output before it acts, builds the evidence — or reveals it is not ready.
That is the intent of the handoff step: documentation, a runbook, and the ability to change prompts, rules, and routing without an engineer. The target is that someone already comfortable administering your existing tools can keep it running — you should not need to hire an ML engineer to own what I hand over.
It is quoted per engagement rather than from a price list, because the same-sounding job can differ by an order of magnitude depending on how many systems it spans and how well defined the process is. Describe the workflow and I will give you a number for it.
Describe the process and the tools it touches. I will tell you honestly whether an agent is the right answer for it.
Get in touch →Got an idea, question, or just want to say hi?