The Echo Angel Orchestrator: A Technical Overview

1 · The accountability gap

When a professional works with an AI assistant, the work gets done — but the record of the work usually does not. Afterward, four questions are hard to answer with anything better than memory: What was intended at each step? What was actually done? Which decisions did a human make, and which did the machine effectively make by default? And what, concretely, could you show a reviewer or an auditor?

Chat transcripts do not answer these questions well. They are long, unstructured, and saturated with the very content that, for professionals in regulated or confidentiality-bound fields, often cannot be retained at all. The usual remedy is policy — ask people to keep notes, write summaries after the fact, reconstruct timelines when someone asks. Voluntary records fail silently — and often on the sessions that later matter.

The Echo Angel Orchestrator takes a structural approach instead: the record is produced as a side effect of doing the work, not as a separate duty after it.

2 · What it is

The orchestrator is a process-governance layer that the professional's own AI assistant works inside. Technically, it is an MCP tool server: a set of model-free tools the assistant calls as it works. The orchestrator contains no model and calls no model; nothing is sent to a vendor model by it. The only model in the loop is yours — the orchestrator adds no new party that sees your content.

Working inside it, a session looks like this:

• Named, resumable, concurrent sessions. Work is organized into sessions with stable names. A session can be picked up days later by name, and multiple sessions can run at once without interfering.
• Phases with declared intent. The assistant declares what a phase of work is for before doing it, and closes the phase when done. Phases left dangling are detected and cleaned up rather than silently lost.
• Timestamped notes. Observations and progress are recorded as they happen, each with a timestamp, building the timeline as the work proceeds.
• Decisions surfaced to a human — with a recommendation. When a judgment call arises, it is raised to the human explicitly, and a recommendation-discipline check governs how it is raised: a decision must come with a recommendation, not be quietly dumped on the person.
• Every governance check recorded with its outcome. When a governance check runs, its firing, outcome, and reason are written into the same durable record as the work itself.
• Record-first: there is no path through the tools that does the work but skips the record.
• Recovery: a process restart loses nothing; a session resumes where it stopped.

Around the sessions sit supporting capabilities: a feedback channel, and a cross-session observation catalog whose entries are retired only through a human-ratified review — recurring lessons accumulate, and a human decides when one no longer applies.

The result is that every session leaves an audit trail — intent, actions, timings, human decision points with recommendations, and governance outcomes — without anyone having had to remember to keep one.

3 · The content-free record

For the most sensitive work, the audit trail itself can be a liability: a record of what was written may be exactly what confidentiality obligations forbid keeping. The orchestrator's flagship privacy property addresses this directly.

A session can be created as a content-free work record: the structure and governance outcomes are kept; the content is never stored. In this mode, the text of intents, notes, and decisions is never written to storage — it cannot leak from a record it never entered. What is kept is the shape of the work: the sessions, the phases, the timings, the fact that decisions were surfaced to a human, and the complete governance audit with every check's outcome.

This claim comes with its verification and its bound, stated plainly:

• Verified: the property was verified live by passing a known sentinel string through the content-bearing paths of a content-free session and then scanning the entire durable record for that string — zero hits.
• Bound: the mode is fixed at session creation and is immutable for the life of the session. It cannot be switched on retroactively to scrub a record, and it cannot be switched off to start capturing content mid-stream.

4 · Reading the record back

An audit trail you cannot inspect is a promise, not a record. The orchestrator exposes any session's structured log on demand, as a tool call — so “audit what was retained” is itself part of the workflow, not an offline forensic exercise. The read-back respects the session's privacy mode: a content-free session reads back with its content verified absent by the sentinel scan, the structure and governance outcomes intact.

Sessions are also isolated between concurrent clients: one assistant process cannot read another's sessions. This guarantee is not theoretical — a defect of exactly this shape was found in real concurrent use and closed, with a regression test. The fix was verified with a two-process acceptance test: under the prior code, one caller's confidential note would have been exposed to another caller; under the fixed code it stayed redacted. For shared multi-tenant deployments, namespace isolation separates tenants' records as well.

5 · What this proves — and what it does not

Honesty about scope is part of the design, so the bounds come first:

• The built-in governance gates are advisory in v1. They record and flag; they do not block. The machinery to halt on a failed check exists, but no shipped built-in gate uses it yet.
• Gate coverage as shipped is deliberately narrow. On the assistant-facing path, every session's audit trail opens with a session-boot governance event, and the recommendation-discipline check governs every decision surfaced to a human. The gate framework is general — every firing is recorded with outcome and reason — but we claim only the checks that ship. A third built-in check exists but does not currently fire on the assistant-facing path; we count it as not shipped.
• The orchestrator tracks and surfaces; it does not make the work good by itself. A faithful record of a careless process is still a record of a careless process. What the orchestrator guarantees is that the process — careful or not — is visible.

The quality of the artifact is governed by the orchestrator's companion, the Echo Angel research application, which ties every claim in a shipped document to a captured source passage and re-checks the exact document at export. The orchestrator governs the process. The app governs the artifact. The only model in the loop is yours. The platform case study (companion document) shows the two layers working together; the application has its own technical whitepaper.

This is a different architecture from assistant products that treat logging as telemetry: here the record is the product's first output, written before governance evaluates it, and readable back by the person it protects.

6 · Evaluation and real use

The orchestrator's evidence is its own audit trail from real production use, stated content-free:

• The session model shipped 2026-06-07 and was live-verified 2026-06-08: the content-free property was verified live by the sentinel scan described above (zero hits across the durable record), and concurrent sessions plus resume-by-name were exercised live.
• The caller-isolation fix shipped after the motivating collision was observed in real concurrent use, and passed its two-process acceptance test. An honest limit at the time of record: the read-back tool's own live exercise, and a final verification with two independent live assistant clients, were still pending operator sign-off.
• Roughly twenty real working sessions existed on the live database at the time of a recent schema migration — the orchestrator governs its makers' own daily work before anyone else's.