Foreman Review: Reliability Gates for Scheduled AI Agents

Scheduled AI agents are the quiet workhorses of modern automation. They post your content, triage your inbox, and compile your morning digest while you sleep. The problem is not that they fail loudly. It is that they fail silently: a repeated topic nobody notices, a run that dies at 95 percent and restarts from zero, a channel whose authorization lapsed weeks ago while every run reported “success.” If you run always-on agents, you have met these failures. You just found out about them late.

Foreman is a new tool built specifically for this problem. It is a set of four reliability gates that sit between your agent and the publish button, and it comes from someone who runs a production fleet of scheduled agents every day. I spent time with the site, the docs, and the open-source skill to see whether it is real engineering or just another wrapper with a landing page. Here is the honest review.

The Verdict

TL;DR: Foreman is four small, dependency-free scripts that enforce hard reliability rules for scheduled AI agents: check your channels before posting, refuse duplicate topics, checkpoint long runs so retries resume instead of restarting, and report every run. The core is free and open source at github.com/grafisify/foreman. A hosted version with fleet-wide dedup and continuous monitoring is on a waitlist. It is genuinely useful, refreshingly honest about what it does not do, and worth trying if you run two or more agents on a schedule. It will not fix bad agent reasoning, and the paid tier does not exist yet outside the waitlist.

What Foreman Actually Is

Foreman is not a framework, not a dashboard, and not a prompt pack. It is four scripts, each with an exit-code contract. Exit 0 means proceed. Exit 1 means stop. As the docs put it: exit codes are contracts, not suggestions.

That distinction matters more than it sounds. Most “reliability” advice for agents lives in prompt instructions: “do not repeat topics,” “verify before posting,” “resume from checkpoints.” A language model can nod along with those instructions and then ignore them. It cannot ignore a non-zero exit code. Foreman encodes the rules in deterministic code that runs outside the model, which is exactly where reliability rules belong. Anthropic’s own guidance on building effective agents makes a similar point: the most reliable systems combine models with deterministic control flow rather than hoping the model behaves.

The four gates run in a fixed pipeline order:

channel_health  ->  dedup_gate  ->  work (checkpoint as you go)  ->  run_report
     (1)                (2)                      (3)                          (4)

A gate that fails stops the pipeline. It never gets worked around.

The Four Gates, Up Close

1. channel_health: refuse to work for a dead channel. Before any run that posts, this gate verifies every posting channel is alive. Exit 1 means a channel is dead, and the rule is blunt: do not post, fix the authorization first. Anyone who has had a social account silently lose its API authorization knows why this exists. The run that “succeeds” while posting to a revoked channel is one of the most common silent failures in scheduled automation.

2. dedup_gate: refuse to repeat yourself. Before choosing what to produce, every candidate topic is checked against a publish registry. Exit 1 means duplicate: stop, pick another topic, and do not reword and retry the same one. The clever part is the ordering. The check happens before the agent spends a single token on the repeat. For fleets that burn API budget on every run, dedup-before-spend is genuine cost hygiene, not just tidiness.

3. checkpoint: never restart from zero. During long runs, each step saves its output as it finishes. On retry, the agent loads the checkpoint and resumes from the failed step instead of replaying the whole run. This is the same idea behind custom hooks that run around agent actions: small deterministic mechanisms that make the non-deterministic part cheaper to operate.

4. run_report: every run ends with a report, no exceptions. When the run finishes, a short summary goes to Telegram if configured, or stdout otherwise. The detail I like most: the report command always exits 0. Reporting must never fail the run. That is the kind of rule that only gets written by someone who has been paged by their own monitoring.

Code on a dark monitor representing a scheduled AI agent run at night

Three Ways to Use It

Foreman comes in three layers, and the boundary between free and paid is documented unusually clearly.

The skill (free). This is the open-source core: the four scripts plus a SKILL.md contract written for AI agents, at github.com/grafisify/foreman. No dependencies beyond Python 3. You run the gates yourself, per project, with a local history file and a local state directory. The docs are explicit that this is the distribution layer, not the product.

The MCP server. The middle layer plugs into any agent client that speaks the Model Context Protocol. Your agent calls Foreman tools directly: check the dedup registry, write a checkpoint, file a run report. Setup is a config block:

{
  "mcpServers": {
    "foreman": {
      "url": "https://foreman.grafisify.com/mcp",
      "headers": { "Authorization": "Bearer $FOREMAN_KEY" }
    }
  }
}

Hosted (paid, waitlist). The managed layer runs the scheduling, execution, metering, and reporting for you. Fleet-wide dedup across agents, checkpoints that survive machine loss, continuous channel monitoring with alerts, and a dashboard. Per-run pricing, nothing to self-host. First slots are opening soon via a waitlist on the site.

CapabilityFree skillForeman Hosted
Who runs the gatesYou, per projectManaged scheduler
Dedup scopeOne history fileFleet-wide, across agents
CheckpointsLocal state directoryDurable, survives machine loss
Channel healthPre-flight check you triggerContinuous monitoring plus alerts
Run reportsYour Telegram botDashboard plus multi-channel
Metering and billingNonePer-run metering
CostFreePaid per run

Where It Comes From

The strongest argument for Foreman is its origin story. It was extracted from a production cron fleet that posts every day, and the site shows a “night shift” log of real incidents the gates caught: a render that failed at 02:14 and resumed at step 4 instead of replaying steps 1 through 3, a repeated topic held at the dedup gate before any tokens were spent on it, an Instagram authorization that had lapsed and was caught by the pre-flight health check before the morning post silently never went out.

These are not hypothetical failure modes from a pitch deck. They are the specific, boring, expensive failures that anyone running scheduled agents recognizes immediately. Tools designed from real incident logs tend to have better instincts than tools designed from first principles, and Foreman’s instincts are good: check before you spend, verify after you post, and never let the absence of news pass as good news. As the log puts it, silence is also a status.

What I Like

Determinism where it counts. The exit-code contract is the whole product thesis, and it is the right one. Guardrails written as prompt text are suggestions. Guardrails written as code that halts the pipeline are guardrails.

Zero dependencies. The skill is stdlib-only Python. No SDK to install, no daemon to run, no database to provision. For a reliability tool, minimalism is a feature: there is less to break, and you can read every line of it in an afternoon.

Dedup before spend. Checking the topic registry before the agent does any work is the kind of ordering decision that saves real money at fleet scale. Most dedup systems check after generation. Foreman checks before it.

Honest failure semantics. The report gate always exits 0 because reporting must never fail the run. The dedup gate refuses reworded retries, not just exact duplicates. These are small rules that reveal a lot of operational scar tissue.

A clear free-versus-paid boundary. The skill itself documents exactly what the hosted tier adds. No feature is vaguely “coming soon” in the free tier to push you toward paying; the free layer is complete on its own terms.

What Gives Me Pause

The hosted tier is waitlist-only. The most compelling parts of the pitch, fleet-wide dedup, durable checkpoints, continuous monitoring, are attached to a product you cannot buy today. What you can use right now is the DIY skill. That is fine, but evaluate Foreman on what exists, not on the roadmap.

The free skill demands discipline. Gates only work if they run on every run, in the right order, with the history file actually updated. Nothing enforces that except you. A gate you skip because the last run was fine is not a gate.

It catches operational failures, not bad judgment. Foreman will stop your agent from repeating a topic, posting to a dead channel, or losing two hours of work. It will not stop it from writing a confident, well-structured, completely wrong article. Architecture decisions, like RAG versus fine-tuning trade-offs or whether your agent should be doing the task at all, which OpenAI’s agents guide covers well, remain your problem.

No third-party track record yet. The evidence for Foreman is the author’s own fleet. That is better than no evidence, and the incident log is specific enough to be credible, but it is still one operator’s experience. Independent users will be the real test.

Local checkpoints do not survive machine loss. In the free skill, checkpoints live in a local state directory. If the machine dies, so does the resume point. Durable checkpoints are a hosted-tier feature, which is fair, but worth knowing before you depend on resume behavior.

Final Verdict: Who Should Try It

If you run one scheduled agent and check on it daily, Foreman is probably overkill. If you run several agents on schedules, especially ones that post to external channels, burn API budget per run, or do multi-step work that hurts to restart, the free skill is worth an afternoon. Wire the four gates into your pipeline in the documented order, keep the history file updated, and see how many silent failures surface in the first week. My guess: more than zero.

The pattern Foreman represents matters beyond the tool itself. As AI coding assistants and agents take over more scheduled work, the reliability layer cannot live inside the prompt. It has to live in code the model cannot negotiate with. Foreman is one of the first tools to package that idea this cleanly, and the price of the lesson is zero.

Get the free skill at github.com/grafisify/foreman, read the SKILL.md contract, and put your agents on the night shift with a foreman watching. If you would rather have the reliability operated for you, join the waitlist at foreman.grafisify.com.

Irfan is a Creative Tech Strategist and the founder of Grafisify. He spends his days testing the latest AI design tools and breaking down complex tech into actionable guides for creators. When he’s not writing, he’s experimenting with generative art or optimizing digital workflows.

Leave a Reply

Your email address will not be published. Required fields are marked *

You might also like
Vector Databases: pgvector vs Pinecone vs Qdrant

Vector Databases: pgvector vs Pinecone vs Qdrant

LLM Structured Outputs: OpenAI vs Anthropic vs Google

LLM Structured Outputs: OpenAI vs Anthropic vs Google

RAG vs Fine-Tuning: When to Use Which

RAG vs Fine-Tuning: When to Use Which

Gemini Skills Explained: Build Your Own AI Assistant

Gemini Skills Explained: Build Your Own AI Assistant

Always-On AI Agents: How They Work and When to Use Them

Always-On AI Agents: How They Work and When to Use Them

Why Small AI Models Win in Production

Why Small AI Models Win in Production