AI agents that keep working when no one is watching.
An agent that only runs when someone calls it is not automation. The Agent Runtime turns it into a dependable service: it wakes on schedules and events, keeps its state, recovers from crashes, and stays inside the budgets and limits you set.
Turn an agent into a service that runs on its own.
Without a runtime an agent only runs when you call it. It has no memory between runs, no schedule, no crash recovery and no limits. The Agent Runtime wraps a Promptise agent in a persistent process that runs on its own.
A function you call
You call agent.ainvoke() by hand. It runs once and stops, with no state between calls, no triggers and no governance. If it crashes, it is gone.
A process that lives
The agent becomes a process: a persistent container with a lifecycle, a trigger queue, a state store, a conversation buffer and a governance engine. It runs until you stop it.
What it gives you
Cron, webhook and file-watch triggers, crash-recovery journals, budget enforcement, health monitoring, missions, secret scoping and a 37-endpoint REST API.
Five layers that make an agent operable.
Triggers wake a process. The process runs the agent. Governance bounds what it does, and management lets you steer it from outside.
Triggers
- Cron
- Webhook
- File watch
- Event bus
- Inbox
Process
- AgentProcess
- Lifecycle
- Context
Agent
- Agent
- Memory
- MCP tools
Governance
- Budget
- Health
- Mission
- Journal
- Secrets
Management
- REST API
- CLI
- Dashboard
- Escalation
Real work looks like an agent that wakes at six, checks your pipelines, finds an anomaly, compares it with yesterday’s deployment, writes a report, posts it and goes back to sleep, without anyone watching.
Work starts the moment something happens.
Triggers compose with OR logic: any one of them can wake the process, and events queue in arrival order. One process can carry as many as it needs.
Cron schedules
Every five minutes, every Monday at 9am, the first of the month. Standard cron syntax.
TriggerConfig(type="cron", cron_expression="0 9 * * MON")Webhooks
GitHub pushes, payments, alerts. Optional HMAC signature verification.
TriggerConfig(type="webhook", webhook_path="/github")File watchers
Glob patterns on a directory, filtered by event type. Process new data as it lands.
TriggerConfig(type="file_watch", watch_path="/data", watch_patterns=["*.csv"])Event subscriptions
React to other agents in the same runtime, by topic with wildcard support.
TriggerConfig(type="event", event_type="pipeline.*")Inter-agent messages
Decoupled coordination between processes through a topic.
TriggerConfig(type="message", topic="coordinator.tasks")Custom triggers
Register your own trigger type and use it like any built-in one.
register_trigger_type(...)Nothing is lost when a process crashes.
Every process keeps persistent state: key-value data with full mutation history, long-term memory, environment variables and file mounts. It is injected into every invocation.
A journal of everything
Two backends: an in-memory journal for tests, and a file journal for production (append-only JSONL with checkpoint files). State transitions, trigger events and invocation results are recorded.
Recovery from the last checkpoint
When the server restarts, the replay engine rebuilds each process from its last checkpoint and replays the events after it, so an agent resumes with its context and counters intact.
- Checkpoints snapshot full process state
- Secrets are never written to the journal
- Restart policy per process: always, on_failure or never
# every process has an AgentContextctx = process.context # read and write state (timestamped, attributed)last_run = ctx.get("last_run_time")errors = ctx.get("error_count", 0)ctx.put("error_count", errors + 1) # long-term memoryhits = ctx.search_memory("previous database migrations")ctx.add_memory("v2 migration finished for orders") # full mutation history of a keyhistory = ctx.state_history("error_count")Autonomy your team can sign off on.
Budgets, health checks, missions and secrets keep an agent inside an envelope. Pick one to see how it is configured.
An envelope the agent cannot exceed.
An autonomous agent can loop for hours, call expensive APIs all night or take irreversible actions while nobody watches. The budget defines what it may do freely, per run and per day, and what happens when it hits the limit.
- Limits on tool calls, LLM turns, cost and irreversible actions per run
- Daily limits on calls, runs and cost, with a configurable reset hour
- Per-tool cost weights, so a payment counts for more than a search
- On exceeding: pause, stop or escalate
budget = BudgetConfig( max_tool_calls_per_run=10, max_cost_per_day=50.0, tool_costs={ "search_database": {"cost_weight": 0.01}, "send_email": {"cost_weight": 0.10}, "process_payment": {"cost_weight": 5.00}, }, on_exceeded="escalate", # pause | stop | escalate)Steer, update and manage agents while they run.
A running agent is not a black box. Let it adapt within limits, message it, and run the fleet from the API, the CLI or a manifest.
Agents that adapt inside guardrails.
Most agents are static: you define one, deploy it and it does exactly that forever. In open mode an agent gets fourteen meta-tools to change itself, coordinate and inspect its own state, within limits you set.
- Self: modify_instructions, create_tool, connect_mcp_server, add_trigger, remove_trigger
- Coordination: spawn_process, list_processes
- Memory: store_memory, search_memory, forget_memory
- Introspection: get_secret, check_budget, check_mission, list_capabilities
- Guardrails: instruction length, custom tool count, MCP URL allow-list, sandboxed tools, spawn limits
Start with one scheduled agent and grow into a fleet.
The runtime is built to be adopted in steps. Each stage adds a capability without a rewrite.
One cron agent
A single AgentProcess with a cron trigger that checks something and reports back. In-memory journal for development.
Add persistence
Switch to the file journal so the agent survives restarts, and use AgentContext for state across invocations.
Several agents
One AgentRuntime manages many processes. The event bus connects them and budgets prevent surprise costs.
Govern and scale out
Health monitoring, missions and scoped secrets, then a multi-node RuntimeCoordinator and YAML manifests.
The runtime is not a replacement for Kubernetes or a scheduler. It is what runs inside them: the part that understands an agent’s state, cost and behavior.
Build agents that run for as long as you need.
Open source under Apache 2.0. pip install promptise to start.