Food Market Hub · Internal

How Otto works

Otto is Kengyew's AI teammate — one identity with two jobs: shepherding code changes until they're live, and turning customer feature requests into paid, delivered work. This page explains every part of Otto, what each part does and remembers, and how the parts add up to an agent that works around the clock and learns from its own mistakes.

One identity · two roles
Checks the world every 30 minutes
Reports to Kengyew 3× daily
Audits itself every Sunday
The operating loop

Six steps, repeated forever

Everything Otto does is one loop. The last step is what makes it different from a script: mistakes change how the next cycle runs.

01

Listen

Capture every message and event on the watched work — including the ones nobody tags Otto in.

02

Understand

Read the whole conversation history, never just the latest message.

03

Decide

Safe things proceed; risky things are drafted and escalated to a human.

04

Act

Reply, fix code, file tickets — then read back proof the action actually landed.

05

Verify

Independent AI skeptics attack every claim before an engineer acts on it.

06

Learn

Every caught mistake becomes a permanent rule that future checks test against.

Anatomy

Two brains, one Otto

Otto runs in two modes that share one memory and one name. Think of it as senses that never sleep, and hands that come online for the heavy work.

The background body

always on · runs every 30 minutes · deliberately limited
  • Watches GitHub, Jira and Discord for anything new on the watched work
  • Drafts replies with a sandboxed AI that has zero tools — it can only produce text, never touch anything
  • Two gates check every draft: is the conversation fully captured, and is the reply actually worth an engineer's attention?
  • Sends Kengyew heartbeats and real-time alarms
  • When unsure — it holds the draft and escalates, never guesses

The session hands

when Kengyew opens a session · full tools · does the real work
  • Reads code, runs tests, writes fixes, opens pull requests
  • Verifies every technical claim against the live source before posting it
  • Executes what the background body escalated
  • Fixes Otto's own machinery when the self-audit finds problems
  • Writes everything it does into the shared ledgers, so the background body never acts on a stale picture
The two jobs

One pipeline, two roles

OTTO-ENGINEER

Steward code to live

Watches every pull request, ticket and thread on the registered work. Answers reviewers, fixes what they flag, resolves conflicts, and drives each change until it's genuinely live — never claiming "done" before the platform proves it.

reviewer comment → captured → understood in full context → reply or code fix → verified → pushed → re-checked live
OTTO-PRODUCT

Turn feature requests into cash

Listens to the #pay-for-fr channel. Filters real, funded requests; asks plain-language questions until the request is specific and testable; drafts the requirements document; and — only on explicit human approval — files the ticket.

customer ask → gate (who/what/budget) → clarify ≤3 rounds → requirements draft → human "file" → Jira ticket → quote → deposit → build → paid
The two roles meet at the Jira ticket: Otto-Product creates it, Otto-Engineer drives it to shipped. One continuous line from customer request to delivered feature.
The components

What Otto is made of

Twelve parts. For each: what it does, how it processes, and what it stores. Everything is a plain file on disk — auditable, versioned, and readable by a human.

📡

The Listener

Every 30 minutes, sweeps all watched surfaces: PR comments, bare approvals, code pushes, merges, reverts, Jira changes, Discord threads (archived ones too), and — crucially — searches the whole organisation for new work touching watched code, so nothing hides outside the registry.
Processescompares each surface against what it has already seen; failures report "could not check X" — a broken sensor never masquerades as a quiet day
Storesnew items in feed.ndjson · seen-ids in seen.json (saved before marked, so a crash can't lose one) · sensor health in health.json
✍️

The Drafting Actor

A deliberately caged AI that reads the full conversation ledger plus the new messages, and produces only text: a reply, an escalation, or silence. It has zero tools — proven by probes, not trusted by promise.
Processesevery draft passes two gates — full-context check and an independent quality grader — before anything can go live; fails closed
Storesdecisions in shadow/records.ndjson · held drafts for the session hands to review
🤲

The Posting Hands

The only parts allowed to touch the outside world: a fixed-vocabulary GitHub tool and allow-listed Discord/Jira senders. The AI never posts directly — it hands text to these, which validate everything.
Processesafter every post, reads back the platform's ID as proof; no proof = retry once, then recorded as FAILED and escalated — "sent" is never assumed
Storesread-back post IDs in the thread ledgers (which the Sunday self-audit re-checks live) · a duplicate-post guard in posted_ledger.json
📖

Thread Ledgers

Otto's long-term memory: one append-only file per conversation, holding every inbound message and every Otto action in full — never truncated, because shortened context once cost weeks.
Processesthe actor reads the complete ledger before every reply; session work appends here too, so both brains share one memory
Storesfull conversation arcs in thread-log/*.md · superseded work carries its predecessor's history forward
🗂️

The Watch Registry

The single list of what Otto cares about: pull requests, Jira tickets, Discord channels. Say "watch this" and it's covered within 30 minutes; every thread Otto posts on adds itself.
Processesdrives which surfaces get swept and which keywords matter; if the file is ever corrupt the system halts loudly rather than fall back to a stale list
Storeswatch.json — with a live-verified status note per item
💰

The FR Pipeline

Otto-Product's engine: gates each request (named customer, contact, problem, urgency, budget), runs plain-language clarify rounds, drafts the requirements document, and tracks the money side — quote, deposit, build, paid — because a filed ticket isn't revenue.
Processesclocks on every waiting state: idle threads get one polite reminder, stalled decisions resurface, below-floor quotes trigger a siren
Storeseach request's state + timestamps in clarify_state.json · answered messages in responded.json · money stages per ticket
📟

Heartbeat & DM Line

Three times a day, a short digest to Kengyew's Discord DM: what moved, what's waiting, what needs him — computed from live reality with ages shown, never from hope. The same DM works in reverse: he can ask or instruct from his phone.
Processesa separate listener reads his messages every 30 minutes; instructions are queued for the session hands, never claimed done by a toolless reader
Storeshis inbound messages + handled-status in dm_inbox.ndjson · last-known state in heartbeat_state.json
🚨

The Escalation Path

When something needs a human — a decision, a fire, a broken sensor — Otto writes a plain-language note: what happened, what it means, what's needed (usually nothing). Critical ones reach Kengyew's DM immediately; the rest batch into digests that flush at three items, or at the first heartbeat after 24 hours.
Processesbefore any escalation repeats an AI claim, it's reconciled against the true outcome record — a held draft can never be described as "posted"
Storespending notes in escalations.d/ · the permanent record in escalations.log
🔒

The Safety Cage

Hard limits that no amount of confidence overrides: no production deploys, no merging, no shared-branch pushes, no spending, no data deletion, no secrets. Risky-but-allowed actions run in shadow mode until a scorecard proves the judgment.
Processesthe cage is tested empirically — probe scripts attempt to break out before every AI call; a breach refuses to run rather than trust
Storesone mode file (RUN_MODE: shadow / escalate_only / paused / live) · confinement attestations per AI version
🧾

The Lessons Ledger

Every caught mistake — wrong claim, missed message, silent failure — becomes a structured entry: what happened, which failure class, who caught it, and the rule that prevents it. Ten real lessons and counting.
Processesgenerates a failure-class checklist that every future verification is required to test against — yesterday's mistake becomes tomorrow's explicit check
Storesstructured entries in lessons.ndjson · human-readable LESSONS.md · the caught-by scoreboard
🔍

The Adversarial Gate

Before any substantive claim reaches an engineer, independent AI skeptics are spawned with one job: prove it wrong. They re-read the live code, re-check every exact name, and test the claim against every recorded failure class.
Processesself-review has caught zero of Otto's mistakes; this gate has caught six — so it's mandatory, and a pass that skipped the lessons checklist doesn't count
Storescorrections posted on the same surface as the original claim — struck through in place, so the wrong version can never be read alone
🪞

The Weekly Self-Audit

Every Sunday, a deterministic program (no AI opinions) reconciles Otto's records against reality: does every claimed post exist on the platform, do the notes match live states, is any human waiting past 48 hours unanswered?
Processesdiscrepancies escalate to Kengyew; a clean week says "records matched reality" out loud — silence is never the success signal
Storesweekly reports as self-audit-DATE.md · trend numbers in metrics.ndjson, including the caught-by scoreboard over time
The daily rhythm

A day in Otto's life

08:00

Morning heartbeat

What's on deck and what decisions Kengyew owes — computed from live queues, every open ask repeated with its age until resolved.

EVERY 30 MINUTES · AROUND THE CLOCK

The tick

The listener sweeps every watched surface plus the whole organisation for new related work. New items flow to the drafting actor; safe replies queue, hard calls escalate. The FR pipeline reads #pay-for-fr the same way and advances its clarify threads and money clocks. Kengyew's DM is read for new instructions.

14:00

Midday heartbeat

Check-in: what moved this morning, what's aging.

WHEN KENGYEW OPENS A SESSION

The hands come online

Otto loads its state, drains everything the background body queued, executes the escalated work — code fixes, verifications, corrections — and logs it all back to the shared ledgers.

18:00

Evening heartbeat

What actually moved today — with proof, not optimism.

ANY MOMENT

Fires don't wait

A production break, an angry engineer, a dead sensor — critical escalations reach Kengyew's DM the moment they happen, not at the next heartbeat.

SUNDAY 21:00

The mirror

The self-audit re-checks a week of Otto's claims against reality and files its findings — including about itself.

The learning loop

How Otto learns from experience

Otto's defining discovery about itself: it cannot catch its own mistakes by re-reading its own work. So learning was made structural — mistakes are captured as data, and the data changes how every future action is checked.

1

A mistake is caught

By a verifier, an audit, or a human — anywhere, any size.

2

It becomes a lesson

Recorded immediately with its failure class and the rule that would have prevented it.

3

Lessons become a checklist

The ledger generates the list of every way Otto has ever been wrong.

4

Skeptics use the checklist

Every future claim is tested against every past failure class before it ships.

5

Sunday closes the loop

The self-audit measures whether records still match reality, and the scoreboard tracks who catches what.

The scoreboard that shaped the design

0
mistakes caught by Otto re-reading its own work
6
caught by independent adversarial verification
4
caught by a human noticing
Ten recorded mistakes. Self-review caught none of them — which is why verification by independent skeptics is mandatory, and why the weekly audit exists. The goal isn't an Otto that never errs; it's an Otto whose errors are caught by machinery before they reach people, and never repeat.
Trust model

What Otto will and won't do alone

Never without a human

  • Deploy to production or merge any pull request
  • Push to shared branches, force-push, or delete data
  • File a Jira ticket from a feature request (explicit "file" only)
  • Spend money, send marketing, touch credentials
  • Chase a reviewer — nudging is Kengyew's call

Always, autonomously

  • Answer every message directed at it — silence is never acceptable
  • Reply, fix, commit and push on watched feature branches
  • Verify every claim against the live source before stating it
  • Correct its own errors on the same surface they were made
  • Escalate anything it isn't sure about — with a recommendation