What's changing in AI — every section, every vendor.

• There are two genuinely different memories, and conflating them is the mistake. Auto-memory is the coding assistant's own notebook: one small file injected verbatim at the start of each conversation, kept tiny on purpose, scoped to a single install — it does not travel with a clone of the code, is never reviewed, and is not shared with a subagent or a second terminal. Durable memory is the opposite by design: every piece lives inside the version-controlled repository, so any agent — a fresh subagent with zero shared history, a different terminal, a future clone on another machine — can read it. The takeaway: decide up front whether a fact is 'this one assistant's note' or 'something the whole team's agents must see,' because those are different stores with different rules, and the second one is the hard one.
• Each layer of the durable side exists because a specific, observed failure mode actually killed real work — and the design maps one answer to each. A mid-session context wipe is answered by a script that fires in the one moment before the loss, plus narrative recovery records the agent writes for itself. A directive given once and never revisited is answered by a durable list of every known piece of work, each with an owner and a trigger, pushed in front of the responsible agent every session. A tracking doc that quietly disagrees with reality is answered by staleness detectors and by saved stamps that openly warn the reader not to trust their own captured values. The reusable idea: don't build one all-purpose memory file — enumerate the distinct ways you have actually seen work get lost, and give each one a mechanism delivered at the right moment.
• The write-up leans on live evidence rather than a diagram. A design mistake from roughly six weeks and dozens of sessions earlier — a visual effect that had been 'shipped' several times while being invisible on the founder's real screen — was correctly cited by a ruling written this week, by a brand-new agent with no memory of the original event, purely because the mistake lives in an append-only committed file that gets read as part of grounding. Separately, one keyword-triggered recall path is built and tested end to end: a registered lesson is injected straight into a fresh subagent's context when its task text matches, and a gate refuses to mark the job done until the lesson was demonstrably used — checked against the actual repository state, never a self-reported 'yes.'
• The most valuable section is the honest-limits one. Most of the enforcement ships in warn-only mode on purpose, to prove zero false alarms before it ever blocks. The largest, richest layer — the accumulated record of past decisions and corrections — is not automatically indexed into any recall mechanism; it still gets found the old way, by an agent choosing to open the file and read it, which worked this week but is not guaranteed to work every time. And no scheduled clean-up pass has ever run to prune duplicates, merge overlapping lessons, or promote raw notes into the fast-recall list. The blunt takeaway: writing a memory down is the easy half; guaranteeing it reaches the right agent at the right moment is the whole game, and this design is candid that it is only partly solved.

4 sources consulted: AI Uni durable-memory research article (internal, authored 2026-07-21) · Memory tool — Claude Platform Docs · mem0 four-scope memory architecture (arXiv 2504.19413) · Sleep-time Compute — Letta

AI Uni engineering research on its own memory architecture, authored on the founder's request to explain it mechanically rather than anecdotally. Every layer described was read directly on disk before writing and cited by exact file path so any claim can be re-checked at the source; external comparisons (a scoped-retrieval memory system, a tiered-memory agent framework with an idle-time consolidation pass, and the platform's own native memory tool) are named against their primary papers or docs, with benchmark numbers flagged as directional because they shift as models change. Honest-state discipline throughout: where a mechanism is tested-and-proven it says so, and where a gap exists (no consolidation pass, a mostly-unindexed record layer) it names the gap rather than glossing it.

• There are three shapes, and they fit different jobs. An open loop — the agent observes, reasons, acts, and picks its own next step — is fine for a single, well-scoped, retryable task with a human reviewing the result. A graph or workflow engine — fixed nodes and edges, state that survives across steps, native checkpoint-and-resume so a crash at step 13 restarts at step 13, not step zero — earns its complexity when you have branching logic and state that must outlive the session. A hybrid — a fixed pipeline with control handed to an agent inside just one or a few bounded steps — is the most common production shape, matching the widely-cited guidance that most systems do not need an autonomous agent, they need a workflow with clear steps, tight tools, and measurable outcomes.
• Each shape has a named failure mode worth knowing before you pick one. An open loop's is the runaway: no termination condition plus an ambiguous tool result can produce hundreds of calls in minutes — mitigated by hard iteration caps, not by hoping. A graph's is stale or duplicate state: child workflows outliving cancelled parents, or a versioning change breaking replay of runs already in flight. The hybrid's is the sneakiest and the most common in practice: the failure moves to the seam, so if the 'deterministic' half is really just instructions living inside the agent's own prompt, you get loop-class failures with graph-class blast radius. The reusable warning: the risky part of a hybrid is exactly the boundary you assumed was safe because you called it deterministic.
• AI Uni's own nightly research build is already a hybrid — a mechanical fetch that invents nothing, then one bounded step where an agent scores and writes, then a mechanical publish that validates and de-duplicates — and a real incident this week proved that the failure is the seam, not the shape. Two defects, both textbook: the wrapper told the agent to run the process 'end to end' but never restated the process's own cleanup step, so the working tree was not restored (it fired three times that week); and the run authored an output file the agent then forgot to include in the change, so it shipped without one of its own results. What did work is worth copying — a preflight step detected the dirty state and escalated instead of silently overwriting, the right behavior to generalize.
• The one-line answer: for these recurring classes, build neither a full graph framework nor an open agentic loop — generalize the hybrid you already have, and move the checkpoint discipline out of the agent's prompt and into the deterministic wrapper, always. Open a durable work record at the trigger, advance it at each stage boundary, and close it only after an explicit terminal-state assertion — tree restored, all generated files staged, output count matches expectation — rather than trusting the agent's say-so. Just as important is the restraint: do not adopt a heavyweight workflow engine to run a handful of daily jobs, do not spin up a multi-agent graph where one authoring step and one separate review step suffice, and do not reinvent a checkpoint format per pipeline when a single durable work record already gives every job one place to show its state.

5 sources consulted: AI Uni orchestration research brief — loops vs graphs vs hybrids for recurring agent work (internal, 2026-07-21/22) · Anthropic — Building Effective Agents · xgrid — Temporal AI agent orchestration: production failure patterns · Diagrid — AI orchestration: workflows for durable AI agents · AgentMarketCap — LangGraph vs Temporal for long-running agent workflows (2026)

AI Uni engineering research on how to orchestrate its own recurring-artifact jobs, grounded in three passes: the external evidence (the canonical workflows-versus-agents framing plus three independent practitioner sources on orchestration failure modes), then its own running machinery read directly on disk, then a per-class recommendation because the jobs genuinely differ. Source discipline is explicit — durability is rated per external finding, single-source claims are flagged as illustrative rather than consensus, and one blocked source was re-checked with a second tool before being treated as inaccessible. The internal incident cited is drawn from the team's own dated defect record, not reconstructed.

• The core insight is small and reusable: cross-session durability was failing not because the loop lacked persistence, but because it had two half-loops that never touched. One half could evaluate a goal and drive a build-then-judge iteration but held its state in memory that dies with the session; the other half persisted work across idle and restart but was goal-blind — it knew a work lane existed, not what 'done' meant or how far along it was. The fix was NOT a new engine. It was one thin durable controller plus ONE shared state cell that both halves read and write. The cell carries only state that genuinely can't be recomputed from artifacts: current step, iteration count, which test is still failing, budget used so far, last-pass timestamp, and a 'gated' flag. Everything else stays stateless and recomputed. The transferable lesson: find the smallest set of state that ISN'T derivable from what's already on disk, and make only that durable.
• Three mechanics make the loop safe to run unattended, each proven by its own test suite. Resume: a killed controller, re-invoked in a fresh process, reads the cell and continues from the saved step and iteration with the failing test recalled — not from step zero (resume suite, 13 pass / 0 fail). Cumulative budget: the turn-and-cost meter hydrates from the cell at the start of every pass, so N restarts enforce ONE budget that halts at the true cap, instead of N fresh budgets — the failure mode that would quietly make an 'unattended for a month' safety claim false (budget-durability suite, 5 pass / 0 fail). Halt-safety: a corrupt, zeroed, or negative budget refuses fail-safe rather than granting a fresh slice, and a loop making no progress halts on a no-progress rule (two identical no-advance passes) or an independent pass ceiling — it cannot spin forever (halt suite, 18 pass / 0 fail). If you build one of these, budget-hydration-from-the-cell is the non-obvious part: a meter with zero persist calls looks correct within a single session and is silently wrong across restarts.
• The team wrote down six named consistency guarantees as the definition of 'durable,' then had an independent seat grade whether each is mechanically proven TODAY — and published the honest grade rather than a claim of six-for-six. The six: G1 work survives a killed terminal; G2 budget is cumulative across restarts; G3 a stuck goal halts and hands back (never a silent sleep); G4 the loop never ships on its own; G5 the goal is the human owner's, not an agent's; G6 the record is append-only and re-renderable (a replay renders identically to the live run). The graded reality: three (G1/G2/G3) have dedicated green commands; two (G4/G5) are proven at the mechanism level but under-cite their strongest defense (a trust-root test, 14 pass / 0 fail) and share one suite instead of each carrying its own command; and one (G6) has NO committed verifier yet — a build spec exists for it, but the check isn't written. The reusable move is the discipline itself: name your guarantees, require each to name its own failing command, and treat 'shares a test with another guarantee' or 'graded by a human' as not-yet-done.
• The two most safety-relevant defenses target a write-capable agent trying to cheat its own loop, and both hold in tests. A trust-root gate (14 pass / 0 fail) rejects a tampered state cell — a schema-valid 'cold-start lie' that fakes a fresh budget or un-parks a goal is refused as un-attested at hydrate — rejects a self-authored human-approval row, and fails CLOSED when the bootstrap secret is unset (no secret, no run). Layered on top, the loop never crosses a human-owner gate on its own: when the work is green but the next step is a ship, a deploy, or one of the eight destructive classes (schema changes, data deletion, secret rotation, auth, payments, production deploy, branch protection, external accounts), the loop reaches a distinct terminal state — PARKED-AT-EYES — that is a VALID stop, not a failure, and it will not self-cross; re-invoking a parked goal keeps it parked. The design deliberately separates the 'done' gate (the machine's job) from the 'ship' gate (always the human's keystroke). One pattern worth stealing: make the ship keystroke structurally impossible for the agent to press, and make an un-attested state cell refuse rather than trust its own file.
• Honest state, stated plainly because it is the most important thing here: this loop is green across its suites and has passed a multi-seat review, and it is NOT live anywhere. The known gaps are documented on disk, not glossed. There is no FOUNDER-ratified operational goal yet — only a schema-proving template that no driver reads; there is no loop state on any production lane; the end-to-end auto-re-wake of a dead terminal is built-and-composed but unproven on a real lane; and, critically, NO dry-run has executed. Go-live is defined as one proven dry-run on a single safe, bounded, recurring real target — the leading candidate is AI Uni's own daily research refresh, which today dies with its session, the exact seam the loop is meant to close — followed by the human owner's explicit go-live word. The takeaway for anyone shipping autonomous infrastructure: 'green in tests' and 'reviewed' are real milestones, but they are not 'live,' and saying so precisely is part of the engineering, not a caveat bolted on afterward.

15 sources consulted: Goal-loop consolidated spec — the ratified 'surgical mend' + durable-controller design — docs/specs/S93-opus-goal-loop-FINAL-PROPOSAL.md · Durable Loop go-live requirements pack — 16 requirements, Gherkin acceptance, honest starting-state gap table — docs/product-requirements/pipeline/DURABLE-LOOP-GOLIVE-REQUIREMENTS-2026-07-13.md · CTO architecture-integrity verdict — the six consistency guarantees enumerated verbatim + graded per-guarantee (under review) — docs/architecture/DURABLE-LOOP-SIX-GUARANTEES-2026-07-13.md · Loop monitoring + maintenance runbook — defines the six guarantees in §5 (merged) — docs/runbooks/DURABLE-LOOP-MONITORING-MAINTENANCE.md · Durable Loop architecture doc (merged) — docs/architecture/DURABLE-LOOP-ARCHITECTURE.md · The durable controller — the mend that drives the goal-contract loop — scripts/harness/goal-loop-controller.mjs · The shared durable state cell — read / write / inspect + HMAC stamp — scripts/harness/goal-state-cell.mjs · FOUNDER-approval binding — content-hash over the goal bytes + a real approval artifact — scripts/harness/founder-approval.mjs · Dead-terminal re-wake transport — scripts/wake-watcher.sh (test-wake-watcher.sh: 21 pass / 0 fail, CTO re-run this session) · Resume-across-session-loss suite — scripts/test-goal-loop-resume.sh (13 pass / 0 fail, CTO re-run this session) · Halt-safety / no-runaway suite — scripts/test-goal-loop-halt.sh (18 pass / 0 fail, CTO re-run this session) · Cumulative-budget durability suite — scripts/test-budget-durability.sh (5 pass / 0 fail, CTO re-run this session) · Trust-root anti-forge / anti-tamper suite (the last gate before unattended-with-write) — scripts/test-f3-trust-root.sh (14 pass / 0 fail, CTO re-run this session) · Import-wiring resolve-on-main suite — scripts/harness/wiring.test.mjs (6 pass / 0 fail, CTO re-run this session) · The schema-proving TEMPLATE goal (explicitly NOT an operational goal; no driver reads it) — scripts/harness/goals/378-roadwork.goal.json

Internal engineering research on AI Uni's own autonomous work loop. Grounded in the FOUNDER-ratified consolidation spec, the built harness scripts on `main`, a Volere-style 16-requirement go-live pack (authored by the Business Analyst), and an independent CTO architecture-integrity verdict; every claim traces to a committed repo artifact by path, and every test count was re-run this session by the CTO on scripts byte-identical to `main` — an independent re-run, so the seat that graded is not the seat that built. Honest-state discipline throughout: the loop is green-in-tests and reviewed but NOT live — no dry-run has executed and go-live is the human owner's explicit word; nothing here claims the loop is running.