The owner loop

MAMA should answer what is happening, how it got there and what changed after a correction. The five checks in INTENT define that outcome. Code provides the path; a real owner turn establishes whether the result is useful.

Understand work in source messages

Connectors retain source content and emit deltas with observation references, source time and observation time. The runtime accepts those deltas into its mailbox. The owner agent receives a bounded view and can use source.search and source.read to investigate the originals.

The agent distinguishes a request, handoff, submission, feedback or delivery from chatter. Source text is quoted as untrusted evidence. Its instructions do not become owner instructions. Collection coverage is separate from work status: no collected update does not establish that nothing changed or that a task finished.

Keep changes with their work item

The owner guidance tells the agent to read existing work before creating a new item. A change belongs on that item’s next revision, with a summary, evidence links, source event time and the roles supported by the conversation. Other tools’ assignments and statuses are evidence for this judgment.

The work ledger stores the current state and its revision history. This is the case container used by the current owner product. It preserves what was requested, what moved, who did what and what remains. File references can retain the locator, version and content hash; originals and generated results should remain distinct versions.

Answer from the stored record

Current-work questions start with memory search and the work ledger. History questions need the revision chain and its supporting evidence. A search preview is navigation: source.read opens the cited original when the stored record does not settle the question.

The owner receives readable sentences. Internal record and observation references remain in stored links and tool traces rather than appearing in the answer. A new session starts with a short block: the local time and the latest owner exchanges. It reads current work and sources with tools rather than receiving them. Restart consistency still needs to be checked with the same owner question after a restart.

Report the same state

A live delta gets two turns in the same session. The first decides only whether to tell the owner and ends in [notify] with owner-facing text or [ack]. Before that reply is routed, the daemon queues a record order for the same messages: the agent revises or creates the work items with links to the messages, updates the board sections that changed (briefing, action_required, decisions, pipeline) and, when the messages settle lasting knowledge, the project’s wiki page, or declares that nothing needs recording. The daemon then checks the ledger for a revision citing those messages or the declaration. A batch with neither waits: it rides with the channel’s next record order, or goes alone five minutes later when no delta comes first. After three attempts in all the daemon logs the batch as lost. Messages more than six hours old when they arrive are not delivered as live deltas.

Scheduled full reports default to 08:00, 13:00 and 18:00 in the configured timezone, which defaults to the machine’s zone. Hourly reminders run from 09:00 through 21:00, with a full report taking precedence in a matching hour. The scheduler records an hour as sent only after delivery succeeds. See reports and board for operation and verification.

A full-report order names the preceding report time, or uses the previous day when none is known. The agent reads the work ledger for changes in that span before writing the report.

The wiki keeps what the sources and the ledger do not show on their own: knowledge that stays true and has to be gathered from many messages, such as a project’s terms, decisions and specifications, and how a client works. What happened stays in the sources, and current state and history stay in the ledger. At reports.daily_hour (23:00 by default) the agent writes the day’s page: the day in brief, what the owner decided, and what was missed and learned. See wiki.

Learn from the next result

Rules that always apply belong in the owner policy file, which the agent holds in every session. Other corrections are saved as scoped lessons. For an owner message, a delta’s notify turn and its record turn, the runtime searches memory with the turn’s text and shows up to three matching lessons, preferences, constraints or workflows, marked as advice rather than facts, and not repeated in the same session on the same day. Record turns and the full-report procedure also list every rule the owner gave in chat, by when it applies, for the agent to read. The agent decides whether they apply.

A saved lesson is evidence of storage. Learning requires a changed result on the next related request, no spillover into an unrelated request, and persistence in a fresh session or after restart. The intent workflow preserves this acceptance test.

Trace the result

Inspect the accepted mailbox input, model run, catalog and native tool traces, stored revisions, and Telegram delivery ledger together. A completed model turn, a database row or a send receipt alone cannot prove that the owner’s question was answered correctly. For uncertain delivery, inspect the existing receipt before repeating the send.

The wiring is in daemon assembly, owner guidance and the report scheduler.