The technology behind Faber

One big job, many focused minds

A single agent carrying an ever-growing context gets slower and less reliable. Faber decomposes approved work into an Atomic Task Graph: tickets with real dependency edges and focused context.

• Independent tickets can run in parallel in isolated Git worktrees.
• Finished branches merge one at a time, with verification before landing.
• A ready-set loop dispatches only work whose prerequisites are complete, and passes validated results downstream.
• Worker preflight checks the runtime, edit path, tests, and commit ability before spending an implementation turn.
• The graph, worker state, and branch ledger are durable so interrupted work can resume safely.

Work that finishes itself

The core loop keeps work moving without quietly converting an unfinished task into a success.

• One focused ticket per turn keeps context bounded.
• Acceptance verification records PASS, FAIL, or UNVERIFIED criterion by criterion; a claim alone cannot close a ticket.
• Deferrals require a reason, loops have no-progress stops, and repair cycles are bounded.
• Graceful handoff carries written progress into a fresh session when context fills.
• Activation work keeps a built result distinct from something that is actually live.

A two-layer conscience

Faber deliberately asks two different questions: did the builder really do what it claimed, and is the delivered result actually correct?

1. The ethics judge: inline, before the report

A separate check reads the builder's work log for unsupported claims, stubs, silent scope narrowing, and missing proof. It can send the work back before the partner report calls it complete.

2. The post-ship auditor: an independent second opinion

A different reviewer examines correctness, security, regressions, and fidelity to the request. Deep review can inspect related files and tests before reporting findings.

The arbiter: a judge for the judges

Before an audit finding becomes repair work, an evidence-only arbiter can disprove false positives against the repository. Confirmed findings can create bounded repair and re-audit work.

The Context Map and the Brain

Faber keeps a small index in context and fetches focused detail on demand rather than replaying a whole codebase or transcript.

The Context Map: routing within a project

Each project has a lightweight map that routes the agent to focused domain documentation. Documentation rides the code commit so the map does not silently drift from the system it describes.

The Faber Brain: knowledge across projects

The Brain holds durable, hard-won knowledge that can help a fresh project session. Project privacy controls keep sensitive work out of shared synthesis.

Hybrid RAG, not a context dump

Retrieval combines full-text search for words and ranking with optional vector embeddings for meaning. If embeddings are unavailable, Faber degrades cleanly to full-text search.

Decisions, event history, lessons, and a reference library are retrievable. Side Chat assembles a bounded pack from the Brain, project map, history, and ticket board so it can answer without starting a full build.

Nothing important is only in memory

Anything that must survive lives in durable storage, and features are checked across refresh, new session, and restart boundaries.

• Turns can resume rather than disappear after an interruption.
• Decisions preserve why a direction was chosen.
• Lessons preserve hard-won root causes.
• Open threads re-enter the loop instead of becoming forgotten promises.
• A user model helps explanations land at the right level over time.

The right model for each job

Faber routes by role, not a single hardcoded model. Translator, summarizer, embedding, and quick-answer roles each have an ordered provider fallback chain.

The builder and auditor are configured independently and intentionally use different models where possible. Supported routes can include subscription sign-in, Codex sign-in, API providers, compatible endpoints, and local models.

Turning failures into a map

Audit findings receive stable failure categories and harness incidents are logged, turning scattered failures into a frequency map. Three confirmed repeats create one durable-prevention ticket or an explicit recorded rationale.

Every repeating workflow writes a cycle receipt and shares a no-progress stop, so continuation, repair, and worker recovery loops cannot spin silently forever.

Plugins and the cloud boundary

The Faber app and the Codex or Claude plugins share one contract: tickets carry acceptance criteria, evidence is explicit, and only an audit verdict can verify work.

The cloud boundary, designed in from day one

Today a plugin uses a local SQLite workspace. The contract already carries a workspace identity so a future hosted control plane can add shared boards, real-time presence, role-based access, and a team Brain without changing how the agent works.