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. A failure holds the worktree and costs no model turn.
• A running wave stays visible and interruptible: workers appear as they spawn, the driving session shows how many are live, and stopping cancels pending builds without abandoning a merge already underway.
• 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.

• A plain request starts work directly: no plan is drawn up first and no tickets are made for it. Planned software work runs from the ticket board, one focused ticket per turn, which 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. A ticket that fails the same way twice, or whose goal cannot be met as written, is blocked and the loop stops and says so.
• Every report names its next action and who owns it: Faber, you, or nothing. A problem that was found and not fixed can never resolve to nothing.
• 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 chain of fix and re-audit has a cap for each turn, and what is left when it stops is kept on the ticket, never dropped.

Looking at the thing itself

A drawing is not reviewed as data alone. The sheets a turn changed are drawn and read by the reviewer as pictures, and a printed package is tiled and read page by page, with one question asked of every sheet: does it contradict itself?

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.

The job record: memory you can read

A project that is not software gets a plain file in its own folder, Faber job record.md: the open items, the decisions and the lessons. It is a view written from Faber's memory after a turn, for people to read. Faber never reads it back as its source of truth.

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.

Vectors made by one embedding model mean nothing to another. Faber records which model made each one, never searches another model's, and makes them again when the model is changed.

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. The helper roles (the plain-English translator, the summarizer, the librarian, Side Chat, the Workspace assistant and post-turn memory work) each have an ordered provider fallback chain and their own time limit, so a model that hangs costs one timeout, not the turn. The embedder is the exception: one model, no fallback, because vectors from two models cannot be mixed.

The builder and auditor are configured independently and intentionally use different models where possible. Supported routes include subscription sign-in, Codex sign-in, API providers, compatible endpoints, and local model servers, which Faber can find on the computer. Each role also has an effort level, from low to max.

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.

A change to a file is planned, written and read back

When Faber changes a workbook, a Word document or a PDF, from chat or in an editor, it does not trust that the write did what was meant.

• Patched, not rebuilt. A workbook or a Word file is a package of parts. Only the parts a change touches are written; the rest, including pictures, charts, macros and print setup, is copied byte for byte.
• Read back and compared. The new file is written beside the old one, opened again, and compared with what was intended: the words, and for a Word document the look of every paragraph, including the ones no edit named. A PDF's pages are drawn again and must show what was there, less what was removed, plus what was added.
• All or nothing. If the comparison fails, the file is left exactly as it was and the refusal says why.
• The file before is kept beside the new one as .bak, and a file or folder you delete is kept for 30 days.
• The other program is the judge. Formulas, number formats and saved files are checked against Excel; a PDF from a document is made by Word from the saved file.

Editors and apps beside Faber

The Workspace editors and the apps you run through the App Browser are separate surfaces. They are first-party and still kept at arm's length.

• The seven Workspace editors are built ahead of time and served by Faber itself: there is no second server to start, and nothing extra to install to run them.
• Faber stays the authority over files. An editor is handed a document by Faber, or asks Faber for it, and a save is a request that Faber checks before anything is written. An editor opened from Faber's page gets its document over an origin-checked message; one opened by its own address, on a phone for one, asks the server itself by the project and the file its address names.
• A save says which version of the file it started from. A text file, a drawing, a picture, a workbook, a Word document or a PDF that was changed on disk since it was opened is not written over: the save is refused and says why.
• A phone reaches Faber over Tailscale only, signed in by a key in the code it scans. The key decides who gets in, and enabling remote access again replaces it, which signs every device out at once.
• A note the Workspace assistant saves for a job is made only when the person's own message asks for one. That is decided by plain rules on the words they typed, never by the model and never by anything a file says.
• A Windows release carries its own copy of Node for one job: running the spreadsheet engine when chat changes a workbook, so the totals chat writes are worked out by the same engine the editor uses.
• Apps in the App Browser are child processes under supervision, so one that crashes or is killed cannot leave an orphan behind, and a sweep at start reaps anything a hard stop stranded.
• One Faber for each port: a second copy refuses to start and names what holds the port, instead of two servers quietly sharing one address.

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.

Teams without a server in the middle

Faber's first step toward shared work needs no cloud: each person's Faber pairs with another by a single-use code and they talk directly over Tailscale, every message signed by the Faber it came from.

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.

These notes match Faber 0.10.79.