9 min readBy agentix-zero

Planning agents for the future: what a platform needs to run them over time

Run logs, a short morning report, a supervising review agent, a release window with veto and four-eyes publishing: what a platform needs for agents, and what exists.

This post is also available in Deutsch.

Most writing about agents is about building one. This post takes the platform’s point of view and asks a different question: what must be in place so that an agent you start today is still running, still useful and still safe in six months, without anyone reading its logs every day? It is partly an opinion piece. We describe five patterns, inspired by publicly discussed agent-operations practice (we copied no code), and we are explicit about which parts openagentix has built, which are planned and which are only our design thinking.

The failure mode: agents stop quietly

A web service that fails pages someone. A scheduled agent that fails usually does not. The routine that summarised dependency alerts every morning simply stops after a credential expires, a model is retired or a schedule is edited by accident. Nothing crashes; the output just never arrives, and nobody notices for weeks. A second, related failure is the opposite: the agent runs but produces empty results every time, which looks like “all quiet” and is not.

Both failures have the same cure: the platform, not the agent, records what happened in a uniform way and something watches the records.

Pattern 1: one uniform run log per routine

Every routine (a scheduled or triggered agent job) writes one record per run, in the same shape, whatever the agent does:

Field Meaning
routine stable identifier of the routine
started_at, ended_at timestamps with offset
duration_ms derived, stored for easy queries
outcome ok, empty or error
cost model and tool cost of this run, in one currency
artifacts references to what it produced: pull request, report, file, ticket

Two details matter more than the field list.

  • empty is its own outcome. A run that finished but found nothing is not the same as a run that did the work. Separating them lets you ask “has this routine produced anything in 14 days?” without guessing.
  • The log is append-only. Runs are never edited or deleted by the agent or by a cleanup job. A correction is a new record that points to the old one. Append-only logs are what make every later pattern trustworthy: a supervisor reading a log the agent can rewrite supervises nothing.

None of this is exotic. It is the same discipline as structured logging and tracing for services, and the OpenTelemetry project’s write-up on AI agent observability discusses the evolving standards for describing agent runs. A run record is the small, durable summary; traces are the detail you keep for debugging. For the detail side, see our post on observability for agents.

Pattern 2: a short morning report per agent

Nobody reads raw run logs daily, so nobody should be asked to. Instead, each agent gets a short report generated from its own run log: what ran since the last report, outcomes, total cost, what it produced, and one line on anything unusual. Five lines is the target. It goes to the owner of the agent, in the place they already look.

The rule that keeps this honest: the report is derived from the run log by a deterministic query plus, at most, a summary step. It is never a free-form claim by the agent about itself. If the report says “3 runs, 1 error”, the run log can prove it. This also gives you a natural place for a service-level view; see SLOs for agents.

Pattern 3: a supervising “chief of staff” review agent

Per-agent reports do not catch what is missing from the reports. For that, a separate supervising agent reads all run logs of a tenant and answers three questions:

  1. Which routines have quietly stopped: scheduled runs that never started, or started and ended error repeatedly?
  2. Which routines have not run for too long compared with their own schedule, or have returned empty for suspiciously many consecutive runs?
  3. What is the cost or duration drift against each routine’s own recent history?

Its output is deliberately small: a short report with at most three recommended moves, ordered by importance (“re-authenticate the connection of routine X”, “pause routine Y, it has errored nine times”). The limit is the design. A supervisor that lists forty findings gets ignored as quickly as the raw logs would. Three forces it to rank.

Constraints we would put on such an agent: it reads run logs and nothing else, it has no write access to the routines it supervises (it recommends, a person or a policy acts, which keeps its agency small, in line with OWASP’s Excessive Agency risk), and its own runs go into the same run log, so that someone can notice if the supervisor itself stops. Who watches the watcher is answered by a plain dead-man check outside the agent system, not by a third agent.

Pattern 4: a release window with veto before anything goes live

Agents that publish things (a blog post, a report, a pull request, an e-mail) should not publish at the moment they finish. Anthropic’s guidance on building effective agents notes that agents can pause for human feedback at checkpoints. A release window puts a deliberate gap between “the agent produced it” and “it is live”:

  • Default: it goes live at its slot. The output carries a scheduled release time. If nobody does anything, it is released then.
  • The owner can put it back before the slot. A veto only holds it back; it deletes nothing. The draft, its history and the run record stay, and it can be released later.
  • Owner approval can release early. If the owner has looked and is happy, approval skips the wait.

The default matters: silence means “proceed at the slot”, not “wait forever”, so an unattended routine keeps working, and the owner’s only duty is to look when they want to. A veto is cheap and reversible, which makes people actually use it.

We run this pattern on this very blog. Posts carry a publication date on a fixed Tuesday or Thursday slot, a merged post stays invisible until its date, and an optional approval field lets the owner release a pair early (approved) or hold it back (vetoed); the agent that drafts posts is not allowed to set that field. The mechanism is described in the repository’s content plan. This is the blog’s build logic, not a feature of the openagentix platform.

Pattern 5: four-eyes publishing, development versus published, scoped secrets

The last pattern is the one companies ask for first (the OWASP Top 10 for Agentic Applications is a good checklist for why): another person must approve before an agent reaches production, as they already do for software. The design we have written down in ADR 0017 has these parts:

  • a four-eyes publish approval, rejectable with review comments, with a per-tenant policy that switches it on;
  • a clear split between an agent in development and a published agent, where edits happen only in development and reach production only after a new publish;
  • an immutable, versioned publish, tagged with a version and a content digest;
  • scoped, encrypted secrets kept per team or tenant instead of personal tokens, with Vault and AWS Secrets Manager as planned backends.

What openagentix does today and what is planned

Built (on main, as of 2026-10-10):

  • An agent has one editable draft and immutable published versions with a content digest; republishing different content under an existing version number is refused.
  • A hash-chained audit trail and cost lines per tenant, agent, use case, run and step (see the roadmap).
  • Run-time approvals for tools.

Planned, not built: the four-eyes publish approval, per-tenant approval policy, review comments, and scoped encrypted secrets with Vault and AWS Secrets Manager backends. ADR 0017 is accepted but not implemented (status “Accepted”), the roadmap item (W14) is marked “not started”, and today the author can publish their own draft and secrets come only from operator-provided environment variables or mounted files. Please do not read “planned” as “available”.

Design thinking only: the uniform run log with the ok/empty/error outcome, the morning report, the chief-of-staff supervisor and the release window with veto are patterns we think a platform needs. We did not find them as roadmap items when we checked on 2026-10-10, so we make no promise about them. The platform already records runs, costs and audit entries, which is the raw material, but the three-field outcome, the reports and the supervisor do not exist as product features.

Historical note on reviews

The original version of this article described an AI-assisted pull-request workflow for the earlier open-agentix platform. That account was specific to its time and does not establish a current review process for every project in the OpenAgentix collection. For consequential changes, I recommend a review by a person who understands the change and its consequences.

What to do now, without a platform feature

You can approximate the first four patterns with what you have:

  1. Define the run record fields above and write one record per run from your scheduler or wrapper, to an append-only store (an object-store bucket with versioning, or a table without update rights).
  2. Generate a five-line daily summary per routine with a query, not a prompt.
  3. Add one supervising job that lists routines with no run, repeated errors or repeated empty, capped at three recommendations, and test it by deliberately stopping a routine.
  4. Put a delay and a hold flag in front of every publish step.
  5. For approval, use the review mechanism your Git host already has, and keep secrets in a secret manager rather than in prompts. Our post on secrets for agents goes into detail.

Key takeaways

  • Agents mostly fail quietly; the platform has to record runs in one uniform, append-only shape and watch the records.
  • Treat empty as a distinct outcome from ok and error.
  • Derive a short daily report from the run log; do not rely on the agent describing itself.
  • A supervising review agent should be read-only and limited to three recommended moves.
  • A release window with a reversible veto lets unattended agents keep working without losing the owner’s control.
  • In openagentix, immutable published versions are built; four-eyes publish approval and scoped encrypted secrets are planned (ADR 0017, proposed), and the other patterns here are design thinking.

Sources

All accessed 2026-10-10. We paraphrase; quotes are short.