Back to site
AI harness

AI harness

The runtime non-human work executes in - one transport for every model call, an ordered gate in front of every tool call, per-employee budgets, and a trace carrying model, prompt hash, tokens and cost

At a glance
01
One invocation contour

every model call goes through a single transport, enforced by a source-scanning boundary test that fails the build on a direct call site

02
Fail-closed tool gate

a write or external call with no approver, an unavailable approver or a throwing approver is denied, and the denial is its own audit event

03
Per-employee budgets

a hard monthly limit per assignment, over-limit when unset, suspension that refuses instead of falling back to a service identity

What this block is

The runtime that non-human work executes in: agents and personas, the skill registry, the tool plane, model providers, retrieval, credits, guardrails, the audit trail, memory - and, since AI employees became subjects of the platform instead of a chat window, identity, a mandate, a position in the org structure and an execution bridge.

It is named for what it is, not for the features it exposes. See AI organisation for the employees this runtime runs.

The layers

Properties worth verifying

Question Mechanism Page
Is there genuinely one path for a model call? Single transport, boundary test in CI, two-entry allowlist Invocation contour
What happens when no approver can answer? Denied - absent, unavailable and throwing approvers all deny Invocation contour
Can a tool ship unclassified? Completeness test over chat-offerable names; unknown maps to external Invocation contour
Can spend be capped per actor? Hard monthly limit per assignment, deny-by-default, suspension Budgets
Is a decision reconstructible? Model id, prompt hash, tokens, cost, latency, attempts - both paths Trace
How is one organisation kept out of another? Schema-per-organisation, everything in this block scoped to it Multi-tenant

The pages

  • Agents that act, not guess - the business view: cloud or on-prem with your own models, a set of specialised agents instead of one chat, and what "acts" means concretely.
  • The invocation contour - one transport, metering composed over it, the ordered tool pipeline, declared risk, resolved configuration.
  • Built for a multi-tenant platform - schema-per-organisation isolation, registry-level integration, agents as subjects in the org structure.
  • Models and providers - provider matrix, model registry, per-agent overrides, per-turn token profile, rate limits.
  • Skills - one registry, four execution kinds, organisation-authored skills, marketplace access enforced at dispatch.
  • Tools and MCP - MCP in both directions, the connector bridge, per-caller authority, progressive disclosure, agent-to-agent.
  • Data scanning and retrieval - the seven-step scan, query patterns and business rules, four layers including what agents learn, hybrid retrieval fused by rank.
  • The decision trace - record contents, both execution paths, denials, redaction.
  • Budgets and metering - metering with no bypass, per-employee limits, suspension, cost per staffing unit.
  • Privacy and on-prem - what stays inside the contour, provider choice, and self-hosted sizing with hardware tiers.

On the roadmap

Kept here so the pages above describe only what runs today.

  • Prompt versioning - a template id and version per prompt module, alongside the content hash the trace already records.
  • A session log as the source of model context - an append-only log the message history is derived from, making replay and forking structural.
  • Provider fallback chains - a second provider taking over mid-request. Held deliberately: which model may substitute for which, and who is billed, is a product decision, not a resilience setting.
  • Attribution of interactive turns to an employee assignment, matching the background paths.
  • Vendor signing and self-serve submission for the skills marketplace.