Contact

Engineering

The engineering behind every decision

Twelve engineering capabilities, each explained by the problem it solves, its architecture and the case where it appears. Diagrams before technology lists.

We describe the design. What is in production at each customer depends on the case, and the evidence for each is labeled.

Architecture

How context, models and agents are organized.

Multi-agent architectures

Illustrative example
The problem
A single generalist agent makes more mistakes and is hard to audit.
Architecture
  1. Goal and policy
  2. Planner splits the task
  3. Specialized agents execute
  4. Policy layer validates
  5. Human approval if needed
Why it matters
Clear roles make each step testable and allow limits per agent.
Where it appears
Agents in the RE/MAX case

Model routing

Proposed architecture
The problem
Not every task needs the largest model, and no model fits every task.
Architecture
  1. Task and requirements
  2. Difficulty classification
  3. Model choice
  4. Output verification
  5. Cost and quality log
Why it matters
It balances quality, cost and latency with an explicit rule.
Where it appears
Intelligence layer

Semantic search

Illustrative example
The problem
Keywords miss what people mean.
Architecture
  1. Text becomes a vector
  2. Vector index
  3. Similarity search
  4. Filter by constraints
  5. Ranking by criteria
Why it matters
It finds what has the same meaning, even when described in other words.
Where it appears
Semantic retrieval in RE/MAX

RAG (retrieval-augmented generation)

Illustrative example
The problem
Models do not know company data and make things up when context is missing.
Architecture
  1. Query
  2. Semantic representation
  3. Source retrieval
  4. Answer with its source
  5. Relevance evaluation
Why it matters
The answer comes from verifiable sources, not from the model’s memory.
Where it appears
Semantic retrieval in RE/MAX

Infrastructure

How execution happens reliably.

Event-driven architectures

Proposed architecture
The problem
Long flows with several steps and systems lose the thread without a record of what happened.
Architecture
  1. State change
  2. Event recorded
  3. Subscribers react
  4. Rebuildable state
  5. Audit
Why it matters
Every step becomes an event, in order, and any case can be rebuilt.
Where it appears
Event log in Subway

State machines

Simulated values
The problem
Processes such as collections and credit have stages and transition rules.
Architecture
  1. Defined states
  2. Allowed transitions
  3. Policy guards
  4. Actions per transition
  5. Absorbing state
Why it matters
The system only does what the transition allows.
Where it appears
Collection states

Distributed execution

Proposed architecture
The problem
Many cases in parallel, with partial failures and retries.
Architecture
  1. Work queue
  2. Parallel execution
  3. Idempotency
  4. Exponential backoff
  5. Completion recorded
Why it matters
Retries do not duplicate actions and one institution failing does not block the others.
Where it appears
Parallel submission in Clave

Integrations

How agents use existing systems.

MCP and tool integrations

Proposed architecture
The problem
Agents are only useful if they reach the systems where the work happens, with permission.
Architecture
  1. Tool described
  2. Permission by purpose
  3. Call by the agent
  4. Result validated
  5. Trace recorded
Why it matters
A standard integration pattern reduces custom code and keeps access control.
Where it appears
Agent OS

Security and governance

How the system respects limits and people.

Security and access control

Proposed architecture
The problem
Personal and financial data require minimal access and a defined purpose.
Architecture
  1. Identity
  2. Minimal permission
  3. Purpose recorded
  4. Audited access
  5. Limited retention
Why it matters
Who accesses what, and why, is recorded and can be reviewed.
Where it appears
Governance in Clave

Human-in-the-loop governance

Simulated values
The problem
Automation without limits decides what it should not.
Architecture
  1. Policy sets the limit
  2. System executes within it
  3. Exception appears
  4. Person decides
  5. Decision recorded
Why it matters
Autonomy has architecture: what exceeds the limit goes to whoever has authority.
Where it appears
Policy simulator

Evaluation

How to know the system is still right.

Evaluation pipelines

Proposed architecture
The problem
Without measuring, a perceived improvement can be a silent regression.
Architecture
  1. Test set
  2. System run
  3. Metrics per task
  4. Baseline comparison
  5. Release decision
Why it matters
Changes ship only when the measurement confirms them.
Where it appears
Evaluation research

AI observability

Proposed architecture
The problem
Models change behavior when data changes.
Architecture
  1. Execution traces
  2. Calibration
  3. Data drift
  4. Human feedback
  5. Threshold re-evaluation
Why it matters
Three monitors (calibration, drift and human feedback) trigger model review.
Where it appears
Observatory

Want to review the architecture with our team?

Tell us the environment and constraints. We reply by the email you provide.

Request a technical briefing