Controlled AI Assistant and Engineering Foundry

The operational problem

Assistant systems become useful exactly when they become dangerous: when they can remember, act, and communicate. The engineering problem is keeping that power inside explicit, inspectable boundaries.

Why the existing approach fails

Most agent demos couple a capable model to open-ended tools and hope prompting holds. There is no consent model, no memory provenance, no staged execution, and no clean human takeover, which makes them unshippable for real work.

What was built

A prototype assistant architecture: consent state machines governing what may be captured and used; a memory store where every entry carries provenance and an approval path; model adapters so no single provider is load-bearing; job-queue ingestion; staged execution where consequential actions require confirmation; and human takeover that pauses automation cleanly. A companion engineering foundry runs build-and-verify loops with test gates.

What the system automates, calculates, and controls

Capture, recall with provenance, drafting, and tool execution inside permission boundaries. The control surfaces are the product.

Where human judgment remains

Everywhere it matters: consent, memory approval, consequential actions, and any communication leaving the system.

How correctness was tested

A phased release plan with a fixture gate at its base: the capture contract is validated against recorded fixtures, schema constraints are tested directly, and each phase must pass its gate before the next unlocks.

What changed

The prototype demonstrates the control architecture Eigenvalue applies to client agent work: bounded permissions, provenance, staged execution, and takeover as first-class design requirements rather than afterthoughts.

Disclosure

Prototype under active development. It is shown as engineering capability, not as a deployed client system.