Engineering
Six disciplines decide whether an enterprise agent works or merely performs. This page states what each one is, what it actually involves, and the warning signs that it has been skipped. It is written for the people who will have to maintain the result.
Each discipline makes one link of the chain hold
Read in order, this is the delivery path. Read as a set, it is a checklist you can hold any agent project against — including one of ours.
Business Data
The records the business already runs on.
Context & Relationships
What those records mean together.
Rules & Permissions
Which rules apply and who may act.
Agent & Tools
The task and the tools it may call.
Validation & Human Oversight
Reconciliation, evaluation, approval.
Business Action
The work changes, and the evidence is kept.
What each one involves
Context Engineering
Deciding what the agent is given, from where, retrieved how, and when it is re-evaluated. Context is the majority of the work and the majority of the failures.
Read more 02Database & Data Engineering
Access paths, joins, reconciliation and the reconciled views that make a source trustworthy enough for an agent to act on.
Read more 03Business Ontology & Semantic Modeling
Turning tables into a business the agent can reason about: entities, definitions, cardinalities, states and the rules that govern them.
Read more 04Agent Workflow & Tool Integration
The tools an agent may call, the contracts they expose, and the permission-aware execution paths they run along.
Read more 05Business Application Engineering
Building the application that carries the work — and being explicit about whether it is a demonstration, a prototype or production-ready.
Read more 06Testing, Permissions & Governance
Evaluation against real scenarios, permission boundaries enforced in code, human approval for consequential actions, and traceability for every run.
Read moreContext Engineering
A general model will answer a question about your business with whatever it believes about businesses like yours. That is not a small gap: it is the whole distance between a plausible paragraph and a decision you can defend.
Context engineering closes that distance by deciding, explicitly, what the agent reads for a given task, from which system, under which conditions, and how conflicting sources are presented to it. It is a design decision with a retrieval system attached — not a prompt with a database mentioned in it.
What this means in practice
- Task-to-source mapping: for each task, the minimum set of records that can answer it.
- Retrieval design: full-text, semantic, structured or a deliberate combination — chosen per source, not globally.
- Context budgets: what gets included, what is summarised, what is deliberately left out, and why.
- Freshness and re-evaluation: when a cached conclusion becomes wrong, and what invalidates it.
- Contradiction handling: when two sources disagree, the agent is told they disagree.
- Sensitivity classification: what may never enter a context window.
Warning signs you have not done this yet
- The team cannot name the source a given answer came from.
- Retrieval was tuned on a demo dataset and never re-checked against production volumes.
- The context window is full of documents nobody has read since the pilot.
- Nobody has decided what happens when two systems report different values.
Database & Data Engineering
Enterprise data is rarely wrong in an obvious way. It is inconsistent in a way a human notices and a machine does not: a contract identifier on a customer record pointing at a contract that does not exist, a billing contact missing on exactly the accounts that matter, a notice window that has already closed.
This discipline exists to make those cases visible. Not to clean the warehouse — to build the view the agent reads, with reconciliation built in, and to report what does not reconcile rather than silently choosing a value.
What this means in practice
- Access-layer design: read paths, permissions and the identity the agent uses.
- Reconciled views: business-meaningful joins presented as one authoritative shape.
- Referential integrity checks: records that point at things which do not exist.
- Freshness and completeness measurement, reported rather than assumed.
- Data-quality rules as versioned code with test cases, not spreadsheet checks.
- A findings report that is read by the business owner, not only by engineering.
Warning signs you have not done this yet
- The agent reports a value that engineering knows contradicts the source system.
- Nobody can say when a table was last reconciled.
- The demo dataset and the production dataset have different shapes.
- Data-quality issues are found by users rather than by checks.
Business Ontology & Semantic Modeling
Six tables and a foreign key are not a business model. A customer is not a row — it is an entity with an identity, a set of relationships, states that change under rules, and definitions that differ between the sales contract and the finance ledger.
The ontology is where those disagreements are made explicit. It is the layer that decides what a renewal opportunity is, when a subscription is genuinely at risk, and which of two conflicting numbers is the one with a defined meaning.
What this means in practice
- Entity definitions with stated identity rules and cardinalities.
- State machines for the objects that move: opportunity, subscription, case, order.
- Definition reconciliation where systems disagree, with an owner for each definition.
- Rules expressed as testable propositions with version, weight and owner.
- A glossary that is part of the system, not a document nobody opens.
- Change control: who may change a definition, and what re-evaluation that triggers.
Warning signs you have not done this yet
- Three teams use the same word to mean different things and nobody has noticed.
- Business rules exist only in people's heads or in an email.
- The agent has to be prompted to know what counts as a renewal.
- A definition change would silently alter historical results and nobody would know.
Agent Workflow & Tool Integration
A tool is not an API call. It is a contract with a defined input shape, a defined failure behaviour, a defined permission, and a defined record of what it did. An agent that can call tools without those four things is a mechanism for producing unexplained changes in a production system.
We design tools read-only by default. Write access is granted per tool, per role, with the permission enforced at the boundary rather than requested politely in the prompt.
What this means in practice
- Tool contracts: typed inputs, declared failure modes, idempotency where relevant.
- MCP, API and service integration chosen per tool rather than globally.
- Least-privilege scope per tool and per role, enforced at the boundary.
- Idempotency and retry semantics, so a retried call does not double-apply.
- Sandboxed execution with time, cost and scope limits.
- Run-level traceability: which tools were called, with what arguments, and what they returned.
Warning signs you have not done this yet
- The agent can write to a system of record and the only control is an instruction in a prompt.
- Tool failures return free text the agent has to interpret.
- There is no record of what the agent actually did in a given run.
- Retrying a tool call can apply an action twice.
Business Application Engineering
An agent that produces a recommendation still needs somewhere for a human to review it, approve it, and see what it did. That surface is an application, and it carries most of the real engineering: authentication, roles, drill-through to source records, audit, error states and the boring parts that decide whether the system is still running in two years.
We state the classification of what we build in writing, because the gap between a demonstration and a production system is where most of the disappointment in this market lives.
What this means in practice
- Explicit classification: demonstration, prototype, or production-ready — defined by what is missing.
- Role-based access in the application, matching the agent's permission model.
- Drill-through from any displayed value to the source records behind it.
- Audit trail for every state change, attributable to a person or an authorised agent.
- AI-assisted features with their own evaluation and a defined fallback when confidence is low.
- Runbooks, documentation and training, as deliverables rather than extras.
Warning signs you have not done this yet
- The pilot worked for forty people and nobody has explained why it stopped there.
- The application cannot show where a number came from.
- Access control was deferred because the pilot team already had the data.
- Nobody can say who did a particular action last month.
Testing, Permissions & Governance
Governance that lives in a policy document is a document. Governance that lives in the permission check, the approval gate and the audit row is a control. The difference is the difference between a control and an intention.
This discipline is what makes an agent acceptable to risk, audit and security functions — and it is a substantial part of the engineering, not a wrapper applied at the end.
What this means in practice
- Evaluation sets built from real scenarios, edge cases and adversarial records.
- Permission boundaries enforced in the query or the API boundary, not in the prompt.
- Human approval gates on consequential or customer-facing actions, naming the required role.
- Decisions recorded with who made them, when, and on what evidence.
- Regression tests that run when a rule, a definition or a retrieval change.
- Traceability: a retained record per run, sufficient to reconstruct what happened.
Warning signs you have not done this yet
- "The AI will not do that" is the only control, and it is a sentence in a prompt.
- Nobody has tested what happens when a record is missing or wrong.
- An approval exists as a button with no record of who pressed it.
- A rule changed last month and nobody knows which prior outputs are now invalid.
See these six working, not described
The demonstration on this site implements all six against one scenario, on synthetic data, with its schema and rules open for inspection — and maps each part of it to the production capability it stands for, so you can see where a demonstration ends and the delivered system begins.