Enterprise Agent Engineering
The layer that decides whether an agent is useful or merely plausible: the business context it reads, the rules that govern it, the tools it may call, and the permission boundary and approval path it operates inside.
The agent answers, but you cannot check it
The prototype worked because the records were curated and the question was narrow. In production the same agent reads eleven systems, three of which disagree with each other, and it produces a confident answer with no indication of which record it relied on.
This is not a prompting problem. It is the absence of engineering: no defined business entities, no explicit rules, no permission model, no reconciliation step and no approval gate. An agent without those is a very fluent way of being wrong at scale, and it will be believed, because it sounds like it knows.
Three audiences, and what each of them actually needs to know
Data and AI engineering
Designing retrieval, semantic models and evaluation that hold up outside the demo.
Enterprise IT and architecture
Making the agent system fit the estate: identity, integration, existing governance.
Business owners
Defining what the agent is allowed to decide, and what has to reach a person before it happens.
The work, in the order we do it
Context engineering
Deciding what the agent is given, from what source, retrieved how, and re-evaluated when. Context is the majority of the work and the majority of the failures.
Data and database engineering
Access paths, joins, semantics, reconciliation and the views that make a source trustworthy. If the records disagree, the agent must be told they disagree rather than picking one.
Business ontology
Entities, definitions, cardinalities and rules written down and versioned. This is the layer that turns six tables into a business the agent can reason about.
Workflow and tool integration
The tools the agent may call, exposed through MCP, APIs or services, each with a defined contract, failure behaviour and permission. Read-only by default; writes are opt-in and audited.
Permission-aware execution
The agent runs as an identity with explicit scopes. It sees what it is entitled to, and it is refused the rest — enforced in the query, not in the prompt.
Human approval and evaluation
Approval gates on consequential actions, plus evaluation against real scenarios and edge cases, with traceability for every run.
Scope and deliverables
| Deliverable | |
|---|---|
| 01 | Business ontology and semantic model |
| 02 | Context and retrieval design |
| 03 | Data access layer, reconciled views, data-quality findings |
| 04 | Tool and API integration contracts |
| 05 | Permission model and enforced boundaries |
| 06 | Rule set, versioned and testable |
| 07 | Approval workflows with recorded decisions |
| 08 | Evaluation harness and run-level traceability |
Prerequisites
What we need from you
- Read access to the systems the work actually runs on.
- Someone who owns the business definitions, not just the databases.
- Agreement on what the agent may decide alone and what must be approved.
- A tolerance for being asked to define things you had assumed were obvious.
Renewal intelligence, and the record that did not exist
A renewal agent is asked to find opportunities needing attention. The records say customer CU-2004 holds contract CT-3003. The customer record also says its contract on file is CT-9999 — which is not in the contract table at all.
An agent without reconciliation reports the opportunity confidently and nobody notices, because the answer looks complete. An agent with a data-quality rule reports the contradiction, refuses to treat the opportunity as reliable, and holds the customer-facing action.
That single check is the difference between a demonstration and an engineered system. It is visible in the demonstration on this site, on a synthetic record that was planted deliberately to be caught.
Composite scenarios drawn from the kinds of constraints we work with. They are not customer case studies and no outcome figures are claimed.
Demonstrations and method
Boundaries — what we will not claim
These are the limits we hold ourselves to, stated up front so you can hold us to them.
- We do not build a system whose behaviour cannot be inspected or explained. If you cannot see why it acted, it is not finished.
- We do not claim accuracy improvements we have not measured against your data.
- We do not put write access behind a prompt instruction. If it can write, the permission model and the audit trail are part of the delivery.
Ask us to engineer one task properly
Bring one workflow that matters and one that would embarrass you if it got it wrong. We will show you the difference in a first technical conversation.