Why AFK?
AFK is designed for engineering teams that need agent systems to be reliable in production, not just functional in a demo.| If you need… | AFK gives you… |
|---|---|
| Predictable multi-step behavior | Deterministic runner loop with typed contracts and explicit lifecycle events |
| Safe tool execution | Pydantic validation, policy gates, approval flows, sandbox profile integration |
| Production controls | Cost/step/time limits, retry and circuit breaker policies, bounded tool outputs |
| Portability across LLM providers | Normalized request/response contracts with pluggable provider adapters |
| CI confidence for prompt and tool changes | Built-in eval suites, golden traces, structured metrics, and telemetry export backends |
The core idea
Every AFK application is built from three pieces:| Piece | What it is | You define |
|---|---|---|
| Agent | A configuration object describing the agent’s identity, model, instructions, tools, and subagents. | Name, model, instructions, tools, subagents, policies |
| Runner | The execution engine that runs agents through a step loop, managing LLM calls, tool execution, and state. | Configuration defaults, telemetry, memory backend |
| AgentResult | The output of a run — containing the final text, run state, tool/subagent execution records, and usage metrics. | Nothing — this is what you read after a run |
What AFK gives you
Typed agents with tool calling
Typed agents with tool calling
Define agents as configuration objects. Attach tools as typed Python functions with Pydantic models for argument validation. The framework handles schema generation, execution, and output sanitization.
Multiple execution modes
Multiple execution modes
Run agents synchronously (blocking), asynchronously (awaitable), or with real-time streaming. Pause, resume, and cancel runs at any point.
Multi-agent orchestration
Multi-agent orchestration
Build systems where a coordinator agent delegates tasks to specialist subagents. AFK manages the DAG execution, join policies, and backpressure automatically.
Policy engine and safety controls
Policy engine and safety controls
Gate tool calls with policy rules. Require human approval for dangerous operations. Set hard limits on steps, cost, and wall time.
Provider-portable LLM runtime
Provider-portable LLM runtime
Swap LLM providers without changing agent code. AFK normalizes requests and responses across OpenAI, Anthropic, and 100+ providers via LiteLLM. Built-in retry, circuit breaking, caching, and rate limiting.
Observability and evals
Observability and evals
Built-in telemetry pipeline with spans and metrics. Eval framework for CI-gated release quality. Export to console, JSON, or OpenTelemetry.
When should you use AFK?
| Scenario | AFK is a good fit | Consider alternatives |
|---|---|---|
| Building a production AI agent with tools | Typed contracts, policy gates, observability | — |
| Prototyping a quick LLM chat | Agent + Runner in 5 lines | Raw API calls may be simpler |
| Multi-agent orchestration | DAG delegation, join policies, backpressure | — |
| Fine-tuning or training models | — | AFK is for inference, not training |
| Simple text completion without tools | Works, but may be more than you need | Direct SDK call is lighter |
| Enterprise deployment with compliance | Policy engine, audit events, secret isolation | — |
Key design decisions
- Contract-first: Every interface is a Pydantic model or Python protocol. Tools, agents, results, and events are all typed contracts — not magic strings.
- Separation of concerns: Orchestration logic (runner, step loop) is completely separate from execution adapters (LLM providers, tool handlers). Swap providers without touching agent code.
- Fail-safe by default: Every agent run has configurable limits on steps, tool calls, cost, and wall time. The runner classifies failures as retryable, terminal, or non-fatal automatically.
- Provider-portable: Your agent code never touches provider-specific types. The LLM runtime normalizes everything into
LLMRequestandLLMResponse.