I built Agent Forge Kit to handle the execution work around an AI agent: running tools, limiting costs, dealing with failures, and resuming interrupted work. Those decisions belong in a runtime that applications can reuse.
An agent defines its behavior. A separate runner decides how that behavior executes. This lets the same agent use different model and storage providers while keeping execution rules consistent.
Deciding what happens after a failure#
Consider a tool that finishes an operation just before the agent process crashes. Restarting from the previous checkpoint could execute the same operation again.
I built recovery around recorded tool effects, checking their inputs before reusing a completed result. A crash-recovery test verifies that a finished effect can be replayed without calling the tool twice. External services still need their own idempotency handling for failures before an effect is recorded.
Working through that case influenced how I treated checkpoints. Saving progress needs to preserve enough information to decide which work can safely run again.
Giving the application control#
The runner enforces limits on steps, tool calls, and cost. It also reports whether a run completed, failed, or stopped at a limit. That gives the application something concrete to act on when an agent cannot finish.
I kept model calls and tool execution behind replaceable interfaces so failure cases can be tested with controlled responses. A provider outage or rejected approval can then be reproduced without waiting for it to happen during a live run.
AFK is published as afk-py, with documentation (opens in a new tab) and source (opens in a new tab). Much of its engineering is in these less visible parts of execution, where a failed run needs to leave the application in an understandable state.