Anna
Anna is a governed, local-first desktop AI agent organized around Home, Cowork, and Crew. This branch preserves the existing product while moving Agent execution into one Node Harness Host and the actual Oh-my-Pi loop.
- Home: personal conversations, task execution, and creation of Skills, prompts, and Python-tool artifacts in the original shared work surface.
- Cowork: business dashboards, Hiker MCP assistance, and existing reimbursement workflows.
- Crew: project graphs, channels, contextual Anna, specialist Workers, artifacts, review, and confirmed project Memory.
The migration replaces Agent execution authority, while retaining business state machines, interfaces, and data. Python may serve identity, business storage, and connectors without model credentials or a legacy Agent loop. Integration and live acceptance are tracked separately; a passing unit test does not establish product readiness.
Current branch: Harness Product-Parity Goal | macOS arm64 | MIT License | CI
Earlier release: v0.2.0 Developer Preview, before the default Harness cutover.
中文 | Development diary | Product walkthrough | Quick start | What you can explore | Architecture
Product walkthrough
The walkthrough records the existing product design retained by the migration. It is not evidence of a live Harness or Hiker run.
One loop across three surfaces: the Create page before a task starts, the complete Cowork Hiker customer-and-contract dashboard, and the Crew workflow canvas. The Hiker view uses synthetic fixture data and contains no real service response, credentials, or business data.
Quick start
Requirements:
- Node.js
>=22.19.0 - Python 3.12 and
uvfor the managed business adapter - macOS arm64, the current desktop validation target
npm ci
uv sync --locked --extra dev
ANNA_OMP_BUN_ARCHIVE_URL=https://github.com/oven-sh/bun/releases/download/bun-v1.3.14/bun-darwin-aarch64.zip npm run harness:omp:prepare
npm run desktop:run
Configure the provider and business connectors locally. Model credentials belong to the Node Host; the Python business adapter receives only its business configuration. Keep configuration and application state outside any Agent-readable workdir.
Prepare the fixed Bun/OMP runtime once per fresh checkout. A worker source change requires a newly bound runtime. The launcher must not fall back to the old Python or Pi Agent loop. See DEVELOPMENT.md for configuration, state isolation, and validation.
What you can explore
| Surface | What it demonstrates |
|---|---|
| Home | Chat/Create, shared LoopCard, workdirs, files/canvas, history, execution controls, and Trace. |
| Cowork | Deterministic Hiker dashboards, an Agent assistant, and existing business approval workflows. |
| Crew | Graph x Channel x Memory, assignment, Worker execution, artifact versions, review, and Showcase. |
| Harness | OMP model/tool iteration with Host-owned context, permissions, Memory, canonical events, and Eval. |
This update brings the preserved product onto the new execution path:
- Home: Chat/Create tasks can run through verified OMP with the configured DeepSeek model, using native Todo, scoped tools, Stop, Trace, durable next-turn context, and reviewable artifacts.
- Cowork: Hiker dashboards and the Agent assistant share the Harness path. The current connected service supports scoped reads; writes still depend on server capability and approval.
- Crew: Contextual Anna and specialist Workers can use project and channel context to draft tasks, produce artifacts, and enter the existing review and rework flow.
- Harness: The Node Host and OMP own model/tool iteration, Memory loading, canonical events, and Eval. Python remains a model-less business and connector adapter.
Each surface is subject to the current Goal's live acceptance gates. Deterministic tests and demonstration fixtures are not evidence of a live provider or external business operation.
Channels and business systems
These workflows are part of the product-preservation contract.
Channels are Anna's collaboration layer. A channel keeps people, Anna, and specialist Agents aligned around the same tasks, active Runs, artifacts, mentions, review decisions, and project history. A message can add context, steer an active execution, request a person or Agent, or return the team to the exact task and artifact under discussion.
MCP is Anna's external-system boundary. Anna can use MCP connectors to retrieve operational data, inspect records, and invoke business operations in ERP or other enterprise systems. Read access stays scoped; external writes retain permission checks, human approval, idempotency, read-back verification, and audit evidence when the connected workflow supports them.
How work moves through Anna
The Agent path is Home / Cowork / Crew -> product adapter -> Node Harness Host -> actual OMP -> Host model transport / ToolGateway -> Contract Eval -> terminal event. Business CRUD and connector operations retain their existing domain services. Agent history, Memory loading, and model/tool authority belong to the Harness.
The product workflow retains explicit approval and review boundaries:
flowchart LR
A[Request] --> B[Run]
B --> C[Context + Skill]
C --> D[Model / Tool / MCP]
D --> E{Approval needed?}
E -->|yes| F[Wait / Review]
E -->|no| G[Artifact]
F --> G
G --> H[Trace + Eval]
H --> I[Continue / Rework / Deliver]
The shared runtime is organized around three durable foundations:
- Identity: workspace, user, channel, and permission scope;
- Judgment: an explicit decision to continue, wait, request information, or finish;
- Memory: a controlled distinction between task context, candidate memory, and confirmed business memory.
When configuration is missing or a connector is unavailable, the state remains visible and recoverable. Anna does not convert an unavailable dependency into a successful result.
Crew
Crew turns multi-person work from a message stream into an observable project graph:
- decompose work with SOP templates and dependencies;
- assign, start, submit, review, approve, and return tasks for rework;
- connect channel messages and artifact cards to concrete nodes;
- inspect project progress and waiting gates from the canvas;
- read and download Markdown or HTML deliverables inside the workflow.
The artifact reader keeps the deliverable, source task, project channel, and approval decision in one review surface.
Harness: the execution and governance layer
Harness v2 focuses on recoverability and evidence quality:
| Capability | Contract |
|---|---|
| Durable Run / Event Store | Persist canonical state and events instead of relying on one live process. |
| Channel-scoped isolation | Keep workspace and channel boundaries explicit. |
| Tool Gateway | Apply schema, permission, approval, idempotency, and audit controls. |
| Memory policy | Separate proposed memory, confirmed memory, and disabled writes. |
| Trace / Eval | Link context, model calls, tools, approvals, retries, and terminal evidence. |
| Scheduler / fencing | Establish controlled proactive runs, ownership, recovery, and duplicate-execution protection. |
The current migration covers the existing Home, Cowork, and Crew Agent paths, including less visible drafting and matching calls. The separate Preview panel is not the product entry. Old Python Agent execution must not act as a fallback.
Longer-term design
| Need | Anna's approach |
|---|---|
| Continue beyond one answer | A Run retains state, events, artifacts, and the next action. |
| Keep automation controlled | External writes retain permission, approval, and audit. |
| Recover from interruption | Waiting, missing configuration, retries, and failure remain explicit states. |
| Review how a result was produced | Trace/Eval evidence connects the execution path to the final artifact. |
| Keep local control | Runtime data stays local by default; external providers and connectors are opt-in. |
| Extend into business domains | Connectors, Skills, and Run Profiles add domain behavior around a shared runtime contract. |
Verification
Run the core repository gates:
npm run typecheck
npm test -- --reporter=dot
npm run frontend:smoke
./.venv/bin/python -m pytest -q
npm run build
npm run release:verify
npm run evidence:verify:all
For the desktop packaging smoke:
npm run desktop:package
npm run desktop:smoke-asar
CI runs deterministic gates without a private provider, local runtime state, or signing identity. Python tests cover the retained business services and the disabled legacy-execution boundary. Real provider and Hiker evidence is recorded separately and is never inferred from fixture tests.
Developer Preview boundary
This release is useful for:
- preserving the original Home, Cowork, and Crew workflows while migrating their Agent execution;
- connecting one OpenAI-compatible provider locally;
- validating scoped tools, execution controls, persistent history, and contextual collabo