Skip to content

Runtime

  • in Runtime
  • 10 min read

Catch a Runaway AI Agent: Behavioral Anomaly Detection

AI agent behavioral anomaly detection is what tells you which way your agent has gone wrong — a poller frozen on get_status(id=42), a search → read cycle that never converges, an agent answering with empty strings, or one whose tool calls are half-failing — by watching the pattern of its calls instead of merely counting them. A runaway agent is not always expensive per call. The quiet failures cost you a whole night of the same cheap request, or a slow drip of trivial replies, while every infrastructure dashboard stays green because CPU and memory look fine. This post shows how the Promptise Foundry runtime catches those failures with four pure-pattern-matching detectors — no extra LLM calls — how to tell a behavioral stall apart from a context-bloat loop so you apply the right fix, and how the runtime pauses or escalates a live process the moment a detector trips.

  • in Runtime
  • 7 min read

AI Agent Crash Recovery with Journals & Replay

AI agent crash recovery is the difference between a long-running agent that shrugs off an OOM kill and one that silently loses hours of accumulated state. A stateless LLM call is easy to retry; an autonomous process that has run 40 invocations, mutated its context, and fired triggers along the way is not. If that process dies and restarts from zero, it re-does completed work, double-fires side effects, and forgets what it learned. This post shows how Promptise Foundry solves that with an append-only journal plus a replay engine — and, just as importantly, where replay honestly cannot help.

  • in Runtime
  • 9 min read

Why AI Agents Double-Fire Actions After a Restart

If you have ever debugged ai agent duplicate actions after restart, you know the failure is never the crash itself — it is what the agent does when it comes back. A stateless retry loop restarts the process from zero, and the agent cheerfully re-runs work it already finished: re-charging a card it already charged, re-sending an email it already sent. The crash was survivable. The re-execution is the incident. This post is specifically about the exactly-once / idempotency failure mode — not general crash recovery — and how Promptise Foundry attacks it with two independent guards: a replay engine that reconstructs state from recorded results instead of re-running completed work, and an irreversible-action budget that caps destructive calls even if the first guard has a bug.

  • in Runtime
  • 7 min read

Fail an AI Agent Over to Another Node After a Crash

AI agent failover to another node is what you actually need when the machine running a long-lived agent dies mid-run — not a fresh agent that boots with an empty head, but the specific crashed process rebuilt where it left off, on a surviving box. Spinning up a replacement is easy. Reconstructing the process that had already scored 128 fraud alerts, advanced a queue cursor, and set its own pipeline_status = "degraded" — on a different machine, from durable evidence — is the hard part. This post shows how Promptise Foundry does that with a RuntimeCoordinator, static or registry discovery, and a shared journal, with no etcd or Consul in the picture. It also draws an honest line against the distributed runtimes other frameworks ship.

  • in Runtime
  • 9 min read

How an Autonomous Agent Knows When Its Goal Is Done

Reliable autonomous agent goal completion is not a boolean the agent emits when it feels finished — it is a judgment an independent evaluator makes about accumulated evidence, and the difference between those two definitions is the difference between an agent you can leave running and one you have to babysit. A long-running agent has to answer a question no single LLM call can answer on its own: is the goal actually done, or does it just look done from inside the transcript? Get that answer wrong in one direction and the agent quits with the job half-finished; get it wrong in the other and it runs on its trigger forever, re-checking work that was completed an hour ago. This post digs into the subsystem Promptise Foundry uses to answer it: a mission — an objective, success criteria, and a periodic LLM-as-judge that scores a persistent process against them until the goal is genuinely met, then auto-completes.

  • in Runtime
  • 7 min read

Governing Autonomous Agents: Budget & Health

Autonomous agent governance is the set of controls that answer the one question every tech lead asks before an agent runs unattended in production: what stops it from looping forever, calling an expensive API 4,000 times, or issuing a refund at 3am with nobody watching? A build_agent() call gives you a capable request-response agent, but the moment you let it run on a trigger with no human in the loop, "capable" is not enough — you need an envelope it cannot exceed. By the end of this post you will know the concrete controls Promptise Foundry ships for that envelope, and how to wrap your own agent in a budget plus a health policy with a real hard stop.

  • in Runtime
  • 7 min read

What Is an Autonomous AI Agent Runtime?

An autonomous AI agent runtime is the layer most tutorials skip: the part that keeps a supervised agent alive, reacting, and recoverable long after your Python script would have exited. Nearly every "build an autonomous agent" post stops at a ReAct while-loop running in python agent.py — one process, no supervision, and everything gone the moment it crashes or you close the terminal. That is a demo, not a system. By the end of this post you'll know exactly what the runtime layer adds, how the AgentProcess lifecycle works, and how to wrap an agent you already have so it survives a restart.

  • in Runtime
  • 8 min read

Durable Execution for AI Agents in Python

Durable execution for AI agents is the property that lets a long-running, self-triggering agent survive a crash and come back exactly where it left off — same context, same counters, same lifecycle state — instead of restarting from zero. The term "durable execution" comes from the workflow world, where engines like Temporal, Restate, and DBOS made it famous. This page explains what the phrase means once your unit of work stops being a deterministic workflow and becomes a stateful agent, why the existing tools only solve half of it, and how Promptise Foundry closes the gap with a supervised process, an append-only journal, and a replay engine. It is the hub for the whole durability cluster, so it stays at the architecture altitude and points you at the deep dives for each mechanism.

  • in Runtime
  • 7 min read

Event, Webhook & File-Watch Triggered Agents

An event-driven AI agent wakes up when something happens in the real world — a webhook fires, a file lands, another service publishes a message — instead of waiting for you to call it or for a clock to tick. Most "autonomous agent" tutorials stop at a cron schedule, which is fine for periodic work but useless when the trigger is external and unpredictable. By the end of this post you'll know the four reactive trigger types Promptise Foundry ships, how to compose several of them on a single process, and how to verify a webhook with HMAC so only trusted callers can wake your agent.

  • in Runtime
  • 8 min read

LangGraph Checkpointing vs Journal-Replay Explained

The honest way to frame langgraph checkpointing vs journaling is not "which one persists state" — both genuinely do — but "what unit each one persists": a LangGraph checkpoint saves the state of a single graph run, while a Promptise journal records the append-only event stream of a long-running, self-triggering process. That distinction sounds academic until a process reboots at 2am mid-run and you need it back exactly where it was. This post draws the line precisely, shows what each mechanism captures, and gives you a runnable script so you can watch a journal rebuild a crashed process from its own event log.

  • in Runtime
  • 6 min read

LangGraph vs Promptise: Long-Running Agents

If you are researching LangGraph vs Promptise for an agent that has to stay alive for hours or days — not just answer one request and exit — you are comparing two different layers of the stack, and it pays to be precise about which one you actually need. LangGraph excels at orchestrating the control flow inside a single invocation. Promptise's Agent Runtime targets the layer above the graph: an OS-level process that wakes on triggers, survives crashes, and stays under governance. By the end of this post you will be able to tell which layer your project needs, and you will have runnable code for a supervised, crash-recoverable agent.

  • in Runtime
  • 7 min read

How to Build a Long-Running AI Agent

Building a long-running AI agent is where most tutorials quietly fall apart: they show you a while True: loop that calls the model, prints a reply, and forgets everything the moment the terminal closes. That loop is not a persistent AI agent — it's a script with a heartbeat problem, no crash recovery, and no way to run more than one thing at a time. By the end of this post you'll understand what a real lifecycle container manages for you, and you'll have a runnable Promptise Foundry agent that keeps living, remembering, and reacting across hours and restarts.

  • in Runtime
  • 10 min read

Rotate an AI Agent's Secret Without Restarting It

To rotate an AI agent's secret without restart, the running process has to be able to swap the credential it holds in memory while it keeps running — and that is precisely the operation most agent stacks make impossible. The usual pattern is to read OPENAI_API_KEY or a downstream service token from the environment once, at construction time, and hand it to a model client or tool. That value is now frozen inside a live object. When the key leaks, expires, or hits its scheduled rotation, your only lever is to rebuild the client — and for a long-running, self-triggering agent, rebuilding means a restart that tears down the accumulated context, the conversation buffer, and the lifecycle state you worked so hard to keep durable. This post shows how Promptise Foundry's runtime makes the secret a per-process governance concern instead: ${ENV_VAR} resolution at start, TTL expiry, hot rotation with no restart, and zero-fill revocation on stop — with the value never written to the journal, checkpoint, or status output.

  • in Runtime
  • 6 min read

How to Schedule an AI Agent with Cron Triggers

Building a scheduled AI agent usually starts with the same advice you find everywhere: wrap your Python script in system crontab and walk away. That works until you notice the agent has no memory of yesterday's run, no record of what it did, and no ceiling on how much it can spend. This post shows you a better pattern — attach a CronTrigger to a persistent AgentProcess so every scheduled run shares a conversation buffer, a durable journal, and governance limits. By the end you will have a cron AI agent running on a real schedule in about five lines of configuration.

  • in Runtime
  • 8 min read

Build Self-Modifying AI Agents with Open Mode

A self-modifying AI agent — one that can rewrite its own prompt, author a new tool, or connect to another server while it's still running — sounds like exactly the kind of thing you should never ship to production. The instinct is right: an agent with unrestricted write access to its own configuration is a liability. But "never" is the wrong lesson. The right one is never without guardrails. By the end of this post you'll know what Promptise Foundry's open mode actually lets an agent do, the concrete safeguards that box it in, and how to enable it in a .agent manifest so an agent can safely author its own first tool.

  • in Runtime
  • 10 min read

Time-Travel Debug an AI Agent by Rewinding State

To time-travel debug an AI agent, you rewind its recorded history to the exact step before it did something baffling, rebuild the state it was actually looking at, and replay its decisions deterministically — instead of squinting at stdout and guessing. When a request/response function misbehaves you set a breakpoint and re-run it. An autonomous agent gives you neither luxury: it woke itself on a trigger you didn't watch, called an LLM whose output you can't reproduce, mutated its own state across dozens of invocations, and fired a side effect you now have to explain. This post shows how a Promptise journal plus its rewind and replay engines turn "why did it do that?" into a reproducible postmortem, and where that differs — honestly — from LangGraph's graph-state time-travel.

  • in Runtime
  • 9 min read

Verify Webhook Signatures Before Waking Your Agent

The code that runs when a webhook hits your service has one deceptively small job: verify webhook signature ai agent triggers before you let them wake anything, because an unauthenticated POST is an open door straight into an autonomous process. This post is not the tour of reactive triggers — that lives in the triggers overview. It is about the one mechanism that decides whether the request is real: HMAC-SHA256 over the raw body, read from X-Webhook-Signature, compared in constant time, and rejected before the agent is ever invoked. Get that check right and the rest of your pipeline inherits a trustworthy entry point. Get it wrong and everything downstream is running on forged input.

  • in Runtime
  • 9 min read

Build a Crash-Safe Watched-Folder Ingestion Agent

A watched folder ingestion agent watches a drop folder, wakes the instant a file lands, and runs an LLM over it — extract, classify, route, emit. This is not a tour of the runtime's trigger types; that overview lives in the Triggers guide. It is one end-to-end build. We wire a FileWatchTrigger to a supervised AgentProcess, and then solve the three things a naive watcher gets wrong the moment it meets production: reprocessing after a crash, an unbounded bill when a thousand files land at once, and losing everything the agent learned between drops. The watch itself is the easy part. The durable, restart-safe pipeline around it is the point.