AI agent development
Agents that take real actions — writing to your database, calling your internal APIs, moving records through your workflow. Every tool gets an explicit definition, a permission boundary and an audit trail.
Independent · AI agent engineering
Agents that survive production.
IREVEX builds AI agents and the harness around them — the routing, evaluation, permissions and tracing that decide whether an agent is a demo or a system you can depend on.
Where the work is
- Interfacechat · API · scheduled job
- Harnessrouting · retries · limits
- Toolstyped · permissioned
- Systemsyour database · your APIs
The model is the easy layer. Everything around it is where projects break.
Built withTypeScriptPythonAnthropic APIPostgreSQLNext.jsAWS
What we are hired to do.
Six things — and they are usually the same project seen from different angles.
Agent harnesses
The model is the smallest part of a working agent. We build the runtime around it: retry and fallback logic, tool routing, memory and context assembly, and hard cost ceilings per run.
Evaluation & observability
Eval suites against your own tasks with a frozen regression baseline, so a prompt or model change either passes or does not. Traces cover every step, tool call and token spend.
Retrieval & data pipelines
Retrieval built against your actual schema and vocabulary, not a generic document blob. Ingestion from source systems, chunking that respects structure, and refresh that keeps answers current.
Integration into live products
Adding agent capability to software that already ships and already has users. We work inside your codebase, respect the existing auth and data model, and roll out behind flags.
Software engineering
The application around the model: front ends, APIs, background workers, storage, deployment and CI. Most agent projects are mostly ordinary software, built to the same standard.
Four stages, in this order.
Most agent projects go wrong at stage three, which is why we budget for it rather than treating it as polish.
01
Scope
What the agent must do, what it is allowed to touch, and how anyone will know it worked.
02
Prototype
A narrow version running against your real data, early enough that the scope can still change.
03
Harden
Evals, tracing, permissions, retries, cost limits. Most agent projects fail here, so this is where the work is.
04
Operate
Into production with monitoring in place, then handed to your team or run by ours.
Discovery sprint
A fixed, short scope for teams deciding what to build. We map the workflow, test the risky assumption with a working prototype, and hand back a written recommendation.
Project build
A defined deliverable with agreed scope, acceptance criteria and handover. You get the running system, the eval suite, the tracing setup and documentation.
Embedded team
An ongoing retainer where our engineers work in your repository, your tracker and your standups — expertise in the room rather than delivered over a wall.
The clearest thing we can show you.
DataSpeak is our own product — a natural-language interface to a data warehouse. Because we own it, we are free to explain exactly how it is built. Client work rarely comes with that permission.
How a question becomes an answer.
Six steps, each one a place a wrong answer can be traced back to. Two of them can be skipped — that is the point of the fourth.
01
The question is classified
A first pass decides whether this is answerable against the connected database at all, and extracts the intent from it. Anything that is not a data question exits here, before a single line of SQL is written.
02
The schema is introspected
Tables, columns, types and relationships are discovered when the database is connected and kept per instance. The prompt is built from that record, narrowed to the tables the instance owner has exposed.
03
Settled definitions are retrieved
Semantic search over previously approved questions, their SQL, and per-table instructions. Rejected attempts come back too, carrying the approver's reason, so they are retrieved as counter-examples rather than patterns to copy.
04
The gap is analysed
What the question asks is compared against what was retrieved. A near-identical prior question confirms tables and columns outright and the selection steps are skipped; a partial match confirms some and leaves the rest open.
05
The query is generated
Tables, then columns, then SQL — three narrow steps with typed structured output rather than one prompt asked to produce a whole query, so a wrong answer localises to a step you can inspect.
06
A person verifies it
The SQL is returned with the rows and can be rated. A rejection opens a review queue; only a correction a maintainer approves is embedded back into retrieval. Nothing edits the system's grounding without a human signing it off.
One correction, in full
“What was revenue by region last quarter?”
01select r.name as region,
02 sum(o.total) as revenue
+02 sum(o.total - o.refunded) as revenue
03from orders o
04join regions r on r.id = o.region_id
05where o.created_at >= '2026-04-01'
06group by r.name
07order by revenue desc;
Line 02 counted refunded orders as revenue. Finance means net. An analyst struck it once; the approved correction is retrieved for every later revenue question on this schema.
| region | revenue |
|---|---|
| North | 128,400 |
| West | 96,150 |
| South | 74,920 |
Synthetic — illustrative schema and figuresorders · regions
Schema first, not prompt first
Introspection runs on connect and is stored per instance — tables, columns, types, relationships. Only tables the owner has exposed reach the prompt, so generation works against the warehouse that exists rather than a guess at what one usually looks like.
The query is part of the answer
The generated SQL is returned beside the rows, never hidden behind them. A result that cannot be read line by line cannot be corrected line by line.
Settled definitions persist
A correction is embedded only after a maintainer approves it, then retrieved as context for the next similar question — so a definition the team has already argued out is not re-litigated.
How it is built.
DataSpeak is in active development and onboarding a small number of teams. We publish no performance figures for it yet.
Why agents specifically.
Ordinary software fails deterministically. An agent fails statistically.
A function either returns the wrong value or it does not. An agent returns the right answer most of the time, and the interesting question is which inputs sit in the remainder. You cannot answer that by reading the code, only by measuring it — which means an evaluation suite, recorded traces and a way to replay a failing case have to exist from the first week rather than being added after the first incident.
Who you talk to
The people writing the code. There is no account layer between you and the engineers.
What we hand over
Running software in your environment, with its tests, traces and evaluation suite. Not a deck.
How we scope
A narrow first slice that reaches production, then widen it once the failure modes are visible.
Contact
Bring us the part that is not working.
A stalled prototype, a harness that keeps timing out, or a problem you suspect an agent might fit.
No account managers and no discovery deck — the first conversation is with an engineer, about specifics. We will say plainly if it is not something we should take on.