01

The problem

Agent frameworks make it easy to let a model act. They make it hard to know what it did, why, on whose authority, and to stop it before an irreversible step.

02

What we engineered

Governance has to sit inside the execution path, not beside it. Every request should pass the same staged pipeline, and the risky ones should wait for a person.

  • 10 department agents, 6 capabilities each: mind, eyes, hands, voice, shield and memory.
  • A ten-stage request pipeline: security gate, session, intent and risk, governance check, cost preflight, model routing, memory recall, request build, streaming, then persist and audit.
  • Two action modes: plan-only by default, and execution that goes through the security gate and an approval queue for high-risk actions.
  • Tiered memory (5 memory tiers) where unverified content expires and permanent tiers need approval.
  • Klyntar, the security layer: scan workflow, evidence checkpoints, a gate that rejects any serious finding without an evidence chain, and a supply-chain scanner.
Daena Brain view with demo data: the governance core, its six capabilities, ten departments such as Engineering, Finance and Legal and Compliance, their agents and demo tool servers, drawn as a network.
03

How it connected

Routing across 10 model providers, with local and cloud runtimes as options, and 116 connectors in the catalog.

04

What technology was appropriate

  • Python and FastAPI (async), SQLAlchemy 2, Pydantic v2; React and TypeScript front end.
  • 9 hard laws enforced in code; tenant isolation at the database layer.
  • Multi-tenant by design; an earlier build runs on Google Cloud Run.
  • Source-available under BSL 1.1, public on GitHub.
05

Where it stands

Beta, with access on request at daena.mas-ai.co. It is the reference architecture we draw on for governed agent builds.

Current state, stated as it is today.

Bring us the bottleneck.

If your problem looks like one of these, tell us. We will say whether a build is the right answer.

Bring us a bottleneck