Sentigent — how it all fits together (diagrams)

The whole system, on a loop

live

You hardly prompt the agent anymore — a loop does. Each lap it reads state from disk, decides the next step using your three layers of context, runs it in a fresh context, then writes progress and goes again until done.

① State — lives on disk, not in the model

▢ ~/.sentigent/loops/<id>.json

goal: ship the CSV export
steps:
  [x] write parser   verified
  [x] add tests      verified
  [ ] wire the CLI   pending
position: 2   attempts: 0

Read fresh every lap. A crash or session limit is just a pause — nothing lives in the model's context.

→reads state
+ 3 layers

② Decide — act or ask, as you would

◆ the loop decides the next move

reads Profile · Plan · Policy
next: "wire the CLI"
act:  true              # confident → go
      ── or ──
ask:  "push to prod?"   # dangerous → you

Confident → it acts. Force-push, prod DB, secrets → it always stops and asks you.

→fresh
context

③ Act & verify — a fresh run, full tools

⟨⟩ fresh claude -p · runs the step

$ wire the CLI
$ pytest -q
3 passed → step verified ✓
# fail → self-repair retry

Nothing counts as done until it passes your check. (Many steps can run in parallel — roadmap X1.)

↺ write progress to disk → next lap reads it fresh → repeat until every step is verified

all steps verified → FAP score, the loop stops

dangerous call or no progress → human gate — you approve & resume

Read it left to right: state on disk → the loop decides using Profile · Plan · Policy → a fresh run does the step and verifies it → progress is written and the lap repeats. It stops when everything's verified (and reports FAP), or hands a dangerous/stuck moment to you. The next diagrams zoom into each part.

The run loop, up close

live

Plan

goal + steps + done-criteria, saved to disk

→

Act

does one step in a fresh context

→

Verify

re-runs your tests / build

✓ passed

go to next step →

✗ failed

self-repair retry, then verify again

? blocked

the clone decides: continue or ask you

Resume

crash, limit, or new session → reloads from disk and keeps going

↺

Repeat

until every step is done & verified

Why it matters: nothing is "done" until it passes your definition of done, a failure triggers a fix instead of a silent pass, and the whole thing survives the end of a session. operator/loop_driver.py

The three layers of context

👤
Individual · Profile
What you would do
your standards + push-vs-ask judgment — written up as a steering file it can re-read
live
📋
Project · Plan
What this work requires
the goal, the plan, done-criteria, and this repo's conventions
live
🛡️
Org · Policy
What everyone is allowed to do
hard rules + a governed catalog of tools/skills the team may use
building

every decision blends all three → decide = Profile · Plan · Policy

The core idea: the loop never has to guess and never stops to ask the obvious, because it holds the context you'd otherwise supply by hand. The more context it has, the more it can safely do on its own.

How it decides: act, ask, or never

live

The clone (soft judgment)

Confident it knows your call → does it, in your voice
Unsure → pauses and asks you (and learns from your answer)
Confidence bar is learned per category — it rises where you've overridden it before

The policy wall (hard, deterministic)

force-push, prod-DB, secrets, rm, external sends
Always stop for you — regardless of confidence
The clone can never clear these on its own

Two layers of safety: a learned judgment on top, an inviolable rule-wall underneath. That's what lets it run unattended without driving off a cliff. operator/resolver.py · core/policy_engine

Free and open source — every layer

Live today — free, local

Individual + Project

The loop, the clone, FAP — on your machine
Your Profile + per-project Plan & guardrails
Auto-written steering file (AGENTS.md)
MIT · nothing leaves your computer

Building — free, self-host

Org · Policy

Org rules enforced across every agent
Capability registry (approved skills · MCP · tools)
Trace & audit · budgets · approval inbox
Team-shared profiles & an org knowledge base

All three layers are free and self-hostable — top to bottom, MIT. The individual + project layers work today; the org layer is being built in the open. Nothing here is for sale.