AI and agent systems

Useful where the work is language. Expensive everywhere else.

Language models are extraordinarily good at a narrow set of things: reading unstructured text, classifying it, drafting a response, pulling structure out of a document. They are a poor and costly substitute for a query, a form or a rule. Most of the value in this line comes from knowing which situation you are in.

Start with a complimentary 20-minute fit call Start with the blueprint

A great deal of what gets asked for as AI is not an AI problem. It is a search problem, a data quality problem, or three fields missing from a form. Where that is the finding, the blueprint says it, and you have saved the most expensive kind of pilot.

What this line covers

Assistants, automation, retrieval and agents, with limits.

Every system in this line needs a boundary drawn around it: what the model may see, what it may do without a human, and what happens when it is confidently wrong. We draw that boundary during discovery, not during a demo.

Assistants that answer from your own material rather than from general knowledge, with the source shown alongside the answer.
Document automation: reading incoming paperwork and turning it into structured records a system can use.
Ticket and inbox automation that classifies, routes and drafts, with a person approving anything that leaves the building.
Retrieval over internal documentation, so the answer comes from the current version rather than from somebody's memory.
Agent workflows that chain steps and call real tools, with approval gates on anything that writes, spends or sends.

Signals you are in this line

Skilled people spend hours reading text to decide where it should go.
The same twenty questions arrive every week and the answers exist in writing already.
Documents arrive in a hundred formats and leave as the same six fields.
A process is judgement heavy at the edges but entirely mechanical in the middle.

The pattern to look for is volume plus language. Without both, conventional software is usually cheaper and more predictable.

The kinds of systems we build

Work the team has taken on in this line.

Built as ordinary software with a model inside it, rather than as a demonstration with software bolted on afterwards.

Ticket triage and drafting

Inbound requests read, classified, enriched with the context a human would have had to look up, and answered with a draft that a person reviews before it goes out.

Document extraction

Unstructured paperwork turned into structured records, with a confidence signal and a review queue for the cases the system should not decide alone.

Retrieval over internal material

Answers grounded in your own documents and quoting them, so the person asking can check the source rather than trust a paragraph.

What we would talk you out of

The findings that save the most money in this line.

This is the service line where a paid discovery pays for itself most often, because the failure mode is a pilot that demonstrates beautifully and cannot be put into production.

Your data is not ready

Retrieval quality is bounded by the material underneath it. If the documentation is stale, contradictory or scattered, a model will reproduce that confidently. Fixing the source comes first.

A rule would be better

Where the decision is deterministic, a rule is cheaper, faster, auditable and correct every time. Models are for the cases rules cannot express.

Nobody has decided who is accountable

Automation that sends, spends or commits needs a named human owner and an approval gate. Where that has not been settled, the blueprint raises it before anything is built rather than after an incident.

Inside the blueprint

What the five days settle before any model is wired in.

The boundaries matter more than the model. These are the questions the blueprint answers for work in this line.

ItemWhat the blueprint settles for this kind of work

What the system may see. Which records, which documents, which customers, and what is excluded from the context entirely.

What it may do unattended. The line between drafting and sending, between suggesting and writing, with the approval gate placed deliberately.

Where a rule beats a model. The parts of the process that should stay deterministic, separated from the parts where language handling earns its cost.

How quality gets measured. What good looks like, how it is checked, and what happens to the cases the system gets wrong, since it will get some wrong.

Privacy and retention. What leaves your environment, what is retained, and what that means for the information you hold about other people.

Running cost, not just build cost. Estimated inference and infrastructure cost at your volume, because in this line the ongoing number often decides the project.

The other three lines

Most projects touch more than one.

Work rarely arrives in a single category. The blueprint is where we decide how much of each one your project actually needs.

Custom business software

Line of business applications, internal tools, dashboards and workflow systems.

Integrations and automation

Making systems talk: APIs, data sync, billing and operations plumbing.

Web and ecommerce platforms

Storefronts, portals and customer facing web applications.

Book the call

Bring the workload, not the technology.

Twenty minutes, no charge. Describe the reading, sorting or drafting your people do by hand and roughly what volume it runs at, and we will tell you whether there is a real system here or an expensive demonstration.

Start with a complimentary 20-minute fit call Read the blueprint in full