InsightLense · capability architecture

Complete observability for AI and agents

Five capabilities a CIO has to be able to evidence once agents are allowed to write to a system of record — and, below that, the full technical architecture for whoever runs the evaluation.

Reference 5 capabilities 60 in the catalogue 9 consuming teams
The executive view

Five things you have to be able to prove

Agents that only draft need very little oversight. The moment one is allowed to change a record — a reserve, a policy, a payment — five questions arrive, and they arrive from five different directions: the board, the auditor, the regulator, finance and your own engineers.

This is the whole platform in one picture. The detail sits further down for whoever does the technical evaluation.

flowchart TB
  Q["Can you prove what your AI did —
and what it was not allowed to do?"] Q --> P1["TRACEABILITY

What the agents did"] Q --> P2["CONTROL

What they could not do"] Q --> P3["AUDIT

What changed in the business"] Q --> P4["ECONOMICS

What it costs to run"] Q --> P5["ASSURANCE

When something breaks"] P1 --> F["Open standards  ·  Runs in your infrastructure  ·  Immutable by design"] P2 --> F P3 --> F P4 --> F P5 --> F style Q fill:#14162b,stroke:#14162b,color:#ffffff style P1 fill:#efecfe,stroke:#4b34e0 style P2 fill:#fbede3,stroke:#b4531b style P3 fill:#e2f5f9,stroke:#0e97b0 style P4 fill:#eef0fb,stroke:#38407a style P5 fill:#f2faf5,stroke:#1d6b3d style F fill:#f6f6fb,stroke:#6b7396
Five capabilities, one foundation. Most AI observability tools deliver the first and stop. The other four are what an auditor, a regulator and a CFO ask for — and they are schema decisions, which is why they cannot be added to eighteen months of history after the fact.
01 · TRACEABILITY

Know what your agents did

Every action an agent took, in order, with the reasoning that led to it — across every system it touched, not just the one it started in.

  • One thread per policy, claim or submission
  • Searchable by the reference your business already uses
  • Works with the instrumentation you already have
02 · CONTROL

Prove what they could not do

Authority enforced by the software rather than requested in a prompt, so a limit is a control rather than a preference — and every refusal is kept as evidence that the guardrail fired.

  • Limits per role and per capability
  • Refusals and escalations recorded, not discarded as errors
  • Human approval captured next to the action it authorised
03 · AUDIT

Show what changed, and who changed it

An immutable record of every business change — the value before, the value after, and whether an agent, a person or a scheduled job did it.

  • Append-only; corrections never overwrite
  • Agent, human and system always distinguishable
  • An examiner's question answered without an engineer
04 · ECONOMICS

Control what it costs

Spend expressed the way a budget holder thinks about it — per cleared submission or per settled claim, not per million tokens.

  • Cost per business outcome
  • Budgets and forecasts per agent, not per API key
  • Restated when prices change, so it reconciles to the invoice
05 · ASSURANCE

Know before someone else tells you

The failure that matters is not an agent doing something wrong. It is a control quietly ceasing to run, which produces no errors at all.

  • Alerts when a control stops firing
  • Incidents that name the exposure, not just the anomaly
  • Standing evidence that the guardrails still work
FOUNDATION

No lock-in, no data egress

The conditions that usually decide whether a platform gets approved at all.

  • OpenTelemetry native — no proprietary SDK, leave whenever you like
  • Self-hosted, VPC or on-premise — no data leaves your estate
  • Immutability enforced at the database, not by convention
Capabilities
5One foundation
Teams served
9One underlying store
Integration
0Lines of application code
Data egress
NoneRuns where you run
For the technical evaluator · layer 1

How data gets in, and how the thread survives a service boundary

The hard part of instrumentation is not emitting records. It is carrying the business thread across services without every developer having to remember to — which is why propagation is three integration points rather than a convention.

flowchart LR
  APP["Your application
agent or service"] --> SDK["Any OTel SDK
OpenLLMetry, OpenInference,
LangChain, Vercel AI, custom"] SDK -->|OTLP/HTTP| ING["/v1/traces"] APP --> MW["Identity middleware
resolve actor + kind
mint or adopt correlation"] MW --> CTX["Request contextvar
correlation + causation"] CTX --> OUT["Outbound HTTP client
X-Correlation-Id
X-Causation-Id"] OUT -.->|next service| MW CTX --> AC["after_commit hook
stamps events on commit,
never before"] AC --> OBX["Outbox
idempotent on event_id"] OBX --> API["Record APIs"] ING --> STORE[("InsightLense
one threaded store")] API --> STORE STORE --> FAN["Fan-out
keep your existing
tracing UI as well"] style ING fill:#e4f4f8,stroke:#0a6e82 style MW fill:#efecfe,stroke:#4b34e0 style AC fill:#efecfe,stroke:#4b34e0 style STORE fill:#14162b,stroke:#4b34e0,color:#fff style FAN fill:#f6f6fb,stroke:#6b7396
Middleware mints when absent and adopts when present. There is no third case and no code path that produces an unthreaded write — a developer adding a new endpoint gets correlation without doing anything.
For the technical evaluator · layer 2

The four primitives and how they join

These are the records you cannot derive from one another, and the reason a model-call log cannot grow into an audit trail: it has no column for an entity, a value, an authority level or a human being.

flowchart TB
  TH(("correlation_id
the business reference
VS-2027-0832950")) TH --- RUN["RUNS
session → span → step
tokens, latency, model,
prompt version"] TH --- AUTH["AUTHORITY DECISIONS
capability, amount,
held vs required,
outcome, approver"] TH --- BIZ["BUSINESS EVENTS
entity, field,
old → new, amount,
actor kind, reason"] TH --- SC["SCORES
target, name, source,
value, comment"] SC -.->|attaches to| RUN SC -.->|attaches to| BIZ AUTH -.->|gates| BIZ RUN -.->|causes| AUTH ACT["ACTORS AND WORKSTATIONS
role, capabilities,
authority per capability,
manager"] --> AUTH ACT --> BIZ style TH fill:#14162b,stroke:#4b34e0,color:#fff style RUN fill:#efecfe,stroke:#4b34e0 style AUTH fill:#fbede3,stroke:#b4531b style BIZ fill:#e2f5f9,stroke:#0e97b0 style SC fill:#eef0fb,stroke:#38407a style ACT fill:#f6f6fb,stroke:#6b7396
Scores attach to runs and to business events alike. That is what lets you ask whether an outcome was good — a reserve set at a sensible level — rather than only whether a model output was good.
The catalogue

The full capability catalogue

The diagram groups them; this enumerates them. Useful as an evaluation checklist whether or not you evaluate us — most of these are things any serious agent observability layer needs to answer for.

LAYER 1 · INGEST

OpenTelemetry native

Standard transport, so instrumentation is never a lock-in decision.

  • OTLP/HTTP ingest at /v1/traces
  • Current GenAI conventionsgen_ai.provider.name, gen_ai.usage.input_tokens
  • Legacy conventionsgen_ai.system, llm.*, traceloop.*
  • Unknown attributes preserved rather than dropped
  • Any SDK — OpenLLMetry, OpenInference, LangChain, Vercel AI, hand-rolled
LAYER 1 · INGEST

Record APIs and delivery

Everything a model-call log has no place for.

  • Business event ingest, single and batch
  • Authority decision ingest
  • Score ingest, single and batch
  • Prompt version registration
  • Outbox pattern with idempotency on event_id
  • Fan-out — keep an existing tracing tool in parallel
LAYER 1 · INGEST

Thread propagation

Three integration points, no per-call discipline required.

  • Identity middleware — mints when absent, adopts when present
  • Correlation id is the business reference, not a UUID
  • Causation id for the immediate parent
  • Outbound headersX-Correlation-Id, X-Causation-Id
  • after_commit emission — never emit before the transaction commits
LAYER 2 · RECORDS

Runs and steps

The engineer's record: what the agent did, in order.

  • Session, trace and span hierarchy with parentage
  • Step inputs and outputs
  • Tokens, latency, model and provider per step
  • Tool calls distinguished from model calls
  • Prompt version recorded at the point of resolution
LAYER 2 · RECORDS

Authority decisions

The supervisor's record. A refusal is a result, not an error.

  • Four outcomes — allowed, refused, escalated, downgraded
  • Level held against level required
  • Amount-aware thresholds, versioned with effective dates
  • Escalation routing and the approver who decided
  • Approver note, retained with the decision
LAYER 2 · RECORDS

Business event ledger

The auditor's record: what actually changed.

  • Append-only, enforced at the database
  • Old value and new value on every change
  • Entity type, field and amount
  • Actor, actor kind and reason
  • Corrections as new events referencing what they correct
LAYER 2 · RECORDS

Scores and actors

Judgement and identity, both first-class.

  • One score primitive — numeric, boolean or categorical
  • Four sources — human, judge, code, feedback
  • Attachable to a run, a step or a business event
  • Actors and workstations — role, capabilities, authority, manager
  • Actor kind — agent, human or system, plus on_behalf_of
LAYER 3 · DERIVED

Economics

Facts are recorded; money is computed, so it can always be restated.

  • Cost derived from traces, never stored at write time
  • Versioned pricing with effective dates and longest-prefix model matching
  • Unpriced models visibly unpriced, never silently zero
  • Cost per business outcome — per policy, per claim, per submission
  • Per-actor budgets, forecast and burn
LAYER 3 · DERIVED

Authority and quality metrics

The numbers that tell you whether the design fits the work.

  • Escalation rate per actor and per capability
  • Approval rate at escalation
  • Autonomy share by count and by value moved
  • Judge / human agreement as a standing metric
  • Prompt version comparison on production outcomes
  • Latency percentiles, throughput and cycle time
LAYER 4 · DETECTION

Rules and coverage

Including the alerts that fire on an absence rather than a spike.

  • Failure rate, spend, latency and SLO rules
  • Control coverage breach — actions over threshold with no authority record
  • Never-fired controls — zero records in a window
  • Field population checks — columns that are always null
  • Escalation collapse — a rate that drops to zero
  • Ledger assertions — invariants that must hold, checked on a schedule
LAYER 4 · RESPONSE

Incidents

An alert that names the exposure, not just the anomaly.

  • Incident records with affected population and value at risk
  • SLA targets and time-to-acknowledge
  • Routing and ownership
  • Remediation tracking linked to the affected threads
  • Bounded windows so the population is defined by two timestamps
LAYER 5 · CONSUMPTION

Views and export

One store, nine audiences, no separate pipelines.

  • Pipeline board and workstation overview
  • Thread view interleaving all record types
  • Run and step tree with a detail drawer
  • Exception register and approval chains
  • Actor breakdown and conformance views
  • Cost, score and version reporting; executive rollups
  • Export — CSV, JSON and query API
Cross-cutting Agent / human / system identity on_behalf_of Append-only enforced at the database Corrections never overwrite Retention policy Access control Self-host, VPC or on-premise No data leaves your estate
Layer 5 in practice

Which capability each team actually touches

An observability layer that only serves engineers gets bought by engineering and renewed by nobody. These are the nine audiences and the capability each one depends on.

TeamAsksDepends on
OperationsWhich pipeline is not behaving like yesterday?Pipeline board, cycle time, coverage alerts
EngineeringWhich code path, and what did it cost?Run and step tree, OTLP ingest, cost per run
Line managersIs my desk escalating too much or too little?Workstation overview, escalation and approval rate
RiskAre the guardrails firing at all?Authority decisions, control coverage, never-fired rules
Internal auditComplete population, remediated, fixed?Exception register, bounded windows, append-only ledger
ComplianceInternal breach or reportable event?Conformance views, actor kind, approval chains
FinanceWhat does it cost, and does it reconcile?Derived cost, versioned pricing, cost per outcome
AI engineeringDid the version we promoted perform better?Prompt version evidence, scores, judge agreement
ExecutiveHow much is autonomous, and what broke?Autonomy share by value, incident rollups
The test that matters

Pick any row. If answering that question in your current stack requires an engineer, an export and a spreadsheet, the capability is missing regardless of how much telemetry you are collecting. Volume of data and answerability are close to unrelated.

Adoption

The order to build it in

Each layer is more useful once the one before it exists. Business events without correlation are a table you cannot join; authority records without business events tell you a gate fired but not what it protected.

STAGE 1

Correlation everywhere

Middleware, contextvars, outbound headers. Use the business reference, not a UUID.

Do this first. It is what makes everything after it useful, and it is the one thing that cannot be retrofitted onto history.

STAGE 2

Business events on what moves money

An after_commit hook on the three or four writes that change a legal or financial position. Old value, new value, actor, actor kind.

Expect to find bugs. Six of the ten defects we found at Vsure surfaced here.

STAGE 3

Authority as returned values

Convert permission checks from raised exceptions into returned decisions, with a downgrade route.

Prerequisite: somewhere to put them, which stage 2 provides.

STAGE 4

Runs via OTLP

Repoint an existing exporter. If you already emit OpenTelemetry this is a configuration change.

Last, not first — it is the layer most teams already have, and the least able to answer an auditor.

Where do your agents already act on real records?

Tell us that, and what you would need to prove about those actions to an auditor. We will set up a hands-on walkthrough within two weeks.

Request a demo →