the short version
How it works, in plain words.
fabrig is a family of tools for building software with agents, and temper is the one you run. This page is written for people. The design documents in the repository are written for agents, and they read that way.
The one idea
Mechanics are code, and judgement is an LLM’s. A model is woken only to produce a change, repair it, review it or resolve a conflict. Queueing, updating and merging are deterministic procedure, and authority enforces the split: agents have no merge or update tool to misuse.
People decide what to build and why, at the level of goals, designs and plans, and step in where agents can’t decide.
Five primitives
Everything temper does is built from five things, which is why so many ways of working fit. Plans, coordinators, chats, goals and reviews are all made from them.
- Task: what is asked.
- Executor: who does it: an agent, a procedure or a person.
- Message: all a task hears once it has started.
- Authority: what it may do. It only narrows when delegated.
- Connector: an external system, such as your forge.
A change, by default
This is the path temper takes out of the box. ✦ marks a model being woken, ■ marks code.
- Produce
An agent is woken to write the change, under a charter and a budget.
- Review
An agent reviews it. This is a gate in the stock landing rule, so it’s a setting you can change.
- Queue
Each landing branch has its own queue. Priorities order it.
- Update
Code brings the change up to date with main. On a conflict, an agent is woken for that alone, to resolve it.
- Gate
Procedure runs the checks. On red, an agent is woken to repair what the gate named, and the gate runs again.
- Merge
Pinned to the commit that was checked, and no other. Landing rules are checked here, whatever a task’s authority says.
- Verify
Slower suites follow main. A red is rerun alone, then bisection assigns the blame.
Changing the path
That path is one of many. You can say any of these to the configuring agent, in your own words.
- Put a person in. Add an approval to a landing rule: how many people, in which role.
- Take a step out. Keep the agent’s review, add a second gate, or drop it.
- Go light where it’s safe. A goal can hold a branch of its own under lighter rules, with its changes landing there quickly and the whole goal checked once before main.
- Route questions. A read-only foreman can answer first, then a coordinator, then you.
- Choose a model per role. Strongest where judgement is dense, cheaper where it isn’t.
- Land by queue or by turn. By turn, gate results are kept per tree, so a tree is proved once.
- Add what you need. Tiers after landing, QA, a second reviewer: each is a charter, and a gate or a delegate.
What no setting moves
- Agents never get a merge or update tool.
- Merging is pinned to an exact commit: the head its decision saw, and no other.
- Delegated authority only narrows, and budgets are carved from the parent’s.
- Effects are made once. An uncertain one waits for a person, not a guess.
- Work outlives processes and machines.
A careful guest on your forge
Repositories are adopted as they are, on Forgejo or GitHub. temper writes only to what it owns, never forces a push, and merges exactly the head its decision saw. A change it didn’t make to what it owns is drift: the work relying on it is held, and nothing is written over.
Underneath
Reliable
- Each kind of write has a recovery class: keyed, conditional, idempotent or unrecoverable.
- Effects go through an outbox, released only after their commit is durable.
- Retry deadlines are absolute and committed before each attempt.
- Fencing uses ordered grace periods.
- Restart follows a fixed script, ending with the outbox settled by key before any new decision.
- Temporal, Inngest and LangGraph give you at-least-once activities and leave idempotency to you.
Scalable
- The target: a ready branch lands first time, within minutes, and no branch waits for another’s fault.
- Merging is pinned to an exact commit, so main’s commit is the gated one.
- Workers dial one engine and scale out across hosts.
- High availability is planned, on a distributed, replicated single-writer KV store (skein-kv).
Flexible
- An executor is an agent, a procedure or a person.
- Templates, charters and landing rules are settings, on jig’s model of tasks and delegation.
- Budgets are carved from a project’s weekly spend, and a task without enough is held.
The family
One repository, five trees, and dependencies that point one way.
| Tree | What it is | Builds on |
|---|---|---|
| skein | One thread, one loop, no async: the io and protocol kit | |
| smith | A protocol-driven agent loop | skein |
| jig | The engine for agentic applications: durable work, authority, effects made once | skein, smith |
| temper | Agent-driven software development on a forge: the part you run | skein, smith, jig |
| hearth | Immutable machines, built from a revision | skein |
The words you’ll meet
You don’t need these to start, since the configuring agent speaks your language. They’re here for when you read a proposal’s settings.
| Goal | A tracked task. Its tree of delegates is its plan. |
|---|---|
| Change | One piece of work on a branch, carried to landing by a procedure. |
| Charter | A role: its instructions, models, tools and limits per run. |
| Template | A way to start work, such as a chat or a goal. |
| Landing rule | What a change must meet before temper merges it: CI, being up to date, gates, approvals. |
| Gate | A check that counts for landing: an agent’s review, or a test workflow. |
| Receipt | A gate’s recorded result for a tree, reused rather than run again. |
| Tier | A slower suite that follows a branch after landing. |
| Coordinator | The agent that shapes a goal’s plan and handles its results. |
| Foreman | A read-only agent that answers a producer’s questions first. |
| Proposal | A request beyond its maker’s authority, waiting for someone who may decide. |
| Revision | The settings as one change left them. A task keeps the charter of the revision it was made in. |