A good agent-native setup

Most AI products are UI-first: screens call a database, and the logic lives in the front end or scattered functions. An agent-native system flips it. You model the domain, expose every action as one audited tool layer, and let both humans and agents drive the system through the same door. The UI becomes a surface over the engine, not the engine itself.

Three rules that change everything

Get these right and the rest follows. Click each one.

The model is the product

Model the domain first, real typed entities and relationships, with an append-only event log. If the model and its actions are right, you can add or swap surfaces (web, email, API) cheaply.

for example A "deal" is a typed object with parties, documents, and a history, not a row glued to one screen. A new email surface is a week, not a rewrite.

How the pieces fit

The capability layer sits at the center. Every surface and every agent reaches the system through it, so authorization and audit happen in exactly one place.

Read top to bottom, it is a stack: thin surfaces on top, one capability layer in the middle, a typed domain and event log at the base.

SURFACES      web app · email · partner API        (thin clients)
DECISION      decision queue · approvals · provenance
AGENTS        orchestrator · scoped agents · LLM gateway
CAPABILITY    one typed, audited tool API          <- humans AND agents
DOMAIN        typed model · append-only event log
PLATFORM      database · object storage · queue · EU hosting

How one action flows

A human action and an agent action take the same path. That is what makes the audit trail trustworthy. Step through it.

01 / 07

Trigger

A human clicks in the UI, or an agent decides to act. Same starting line.

The layers, one by one

Each layer has a single job. Click each one.

Domain + events

A typed, normalised data model as the single source of truth, plus an append-only event log of every change. Migrations are reviewed code, not the AI editing the database.

for example Deal, Mandate, Document, Valuation, Party, plus an immutable stream recording who or what changed each one, when, and with which inputs.

Scope agents narrowly

One agent improvising over an entire process is the classic failure mode: it demos well and underdelivers. Prefer small, named agents with narrow remits, wired into deterministic workflows with gates between steps.

Narrow remit

Each agent does one job and is tested in isolation, so reliability is something you engineer, not hope for.

Own tools and knowledge

An agent only touches the capabilities and context its job needs. Least privilege, by design.

Deterministic spine

The workflow is a defined pipeline; agents power the steps. The orchestration is predictable; the intelligence is inside it.

UI-first vs agent-native

UI-first (the trap)	Agent-native
Screens call the database directly	Surfaces call one capability layer
Logic in the front end / scattered functions	Logic in typed, audited capabilities
Agents bolted on, with their own path	Humans and agents share the same tools
A pile of tables	A typed domain model + event log
Audit and security ad hoc	Append-only audit, authz in one place
One web surface, hard to extend	Web, email, API over one engine
Provider lock-in	A gateway, multi-provider, swappable

Get there without a big-bang rewrite

You do not stop and rebuild for a year. You strangle the old app one workflow at a time:

Model and capability layer first. Define the domain and core tools; wrap the existing database behind the new service API. Stop new direct-from-frontend access.
Move one workflow onto the new tool layer and agent orchestration, behind the existing UI.
Add the event log and provenance early, so trust and audit exist before scale.
Evals and tracing before more autonomy. Earn reliability one workflow at a time.
Thin the UI and add surfaces as the engine proves out.