What should you build with AI inside your company, and how do the systems talk to each other?
Build the things that depend on your own documents, your own processes, and your own permissions: a knowledge base your staff can ask questions of, agents that draft the repetitive work, retrieval over the policies and contracts you already have. Buy everything generic. We build internal tools only, with a named approver on every action that leaves the building, and we do not build customer-facing AI products.
- Is the error cheap to undo?A wrong ticket category costs ten seconds. A wrong firewall change costs a weekend. Start with the first kind.
- Is there volume?Four minutes saved on a task done forty times a day is worth building. An hour saved monthly is a distraction until the first kind are done.
- Can you measure it?Before and after, in the same units. No baseline, no result.
- Is there a named approver?not a teamEvery action that leaves the internal boundary or changes a system of record has a person attached to it.
Anything failing the first or the last does not get built, whatever the vendor demo showed.
AI Automation & Integration
Start with the inventory, not the tool
Two weeks, before anyone opens a model. We pull the work as it actually happens (tickets, requests, reports, reconciliations, whatever your unit is), categorize it, and time it. Then we rank by hours consumed multiplied by how cheaply a mistake is undone.
That ranking usually surprises people. The process everyone complains about is rarely the one eating the most hours, and the one eating the most hours is often boring enough that nobody had thought to mention it.
We have written up the tests we apply in what to automate with AI agents first. The short version: high volume, cheap to undo, measurable, and with a named approver. Anything failing the first or the last does not get built.
Three things we build most often
A company knowledge base
Retrieval over the documents you already have, respecting the permissions you already enforce, answering the questions your staff ask each other in chat all day. It cites its sources, so an answer can be checked rather than trusted.
The hard part is not the retrieval. It is deciding what goes in, keeping it current, and handling the documents that contradict each other. That last one usually turns into a document alignment engagement under AI Strategy & Governance.
Questionnaire and proposal drafting
If you sell to enterprises, you answer the same security questionnaire twenty times a year with slightly different wording. We build retrieval over your policies and your prior answers that drafts each response for a human to approve, which turns a multi-week review into days.
This pairs with the SOC 2 control mapping work, because the drafts are only as good as the policy corpus behind them.
Private and local models
When data cannot leave the building, we deploy open-weight models on your own hardware or private cloud and build the same tooling against them. We run local models ourselves, which means we can tell you precisely where they fall short of frontier models rather than discovering it in production.
The rule we do not bend
Every action that leaves the internal boundary, changes a system of record, or reaches a customer has a person attached to it. Not a team. A person, by name, with the action logged.
This is not caution about model quality. It is that accountability cannot be delegated to software, and the organizations that learned this the expensive way in 2025 and 2026 did not fail because the model was bad. They failed because when something went wrong, nobody could say who had approved it.
Handover is part of the build
We are done when your team can change what we built without us. That means runbooks, the evaluation harness, and at least one of your engineers who has made a change to the system under our supervision before we leave.
If a consultant has to stay for the thing to keep working, you bought a dependency rather than a capability. Ask any vendor, including us, what happens to their build in six months if you stop paying them.
What you get
- An automation inventory ranked by hours saved and by how cheaply an error is undone
- APIs built and connected: the integrations between systems that do not talk to each other, with contracts, versioning, and error handling designed rather than discovered
- Agents and workflows for the work that survives that ranking, built narrow before they are built wide
- Retrieval over your internal documents, respecting the permissions you already enforce
- A company knowledge base your staff can ask questions of, grounded in sources it cites
- Private or local model deployment where data cannot leave your network
- An evaluation harness: how each system is tested before a change ships, and how it is monitored after
- Approval gates and logging on every action that touches a customer or a system of record
- Handover runbooks, so your team can change what we built without calling us
- Baselines before and after, in hours or cycle time, measured the same way on both sides
Questions we get
- Build or buy?
- Buy anything that is not specific to your company: transcription, translation, summarization of public material, general coding assistance. Build what depends on your documents, your permissions, your processes, and your history. The dividing line is whether a competitor could use the same thing unchanged.
- Can you run models on our own hardware?
- Yes, and sometimes we recommend it. Open-weight models on your own servers or private cloud, with the same tooling built against them. They are not as capable as frontier models, and we will tell you exactly where that shows up, but when data genuinely cannot leave the building the trade is worth it.
- What stops an agent doing something expensive?
- The boundary is written before anything is built: what the agent may read, what it may write, what it must ask about, and what it may never touch. Administrator rights, money movement, production changes, and customer communication are on the never list by default. Every action outside a read is logged with the person who approved it.
- How long before it pays for itself?
- The honest answer is that it depends on the hours you are currently spending on the work. The inventory in week one puts a number on that before you commit to a build, which is the point of doing it first. If the number is not compelling we say so.
- What happens when the models change?
- Your evaluation harness catches it. That is why we build one before we build the agent: a set of real cases with known-good outcomes that runs against any model change. Without it, a vendor upgrade silently degrades your tool and nobody finds out from a dashboard.
How it starts
Two-week automation inventory, then four to eight weeks per build. You keep everything produced, whether or not there is a next part.