Your first agent
Agent fields reference
| Field | Type | Default | Purpose |
|---|---|---|---|
model | str or LLM | required | LLM model name or pre-built client instance |
name | str | None | Agent identity for logs, telemetry, and subagent routing |
instructions | str | None | System prompt — what the agent knows and how it behaves |
instruction_file | str or Path | None | Path to a .txt or .md file containing the system prompt |
prompts_dir | str or Path | None | Directory containing prompt files resolved by the prompt store |
tools | list[tool] | None | Typed functions the agent can call |
subagents | list[Agent] | None | Specialist agents this agent can delegate to |
skills | list[str] | None | Skill names to resolve from skills_dir |
skills_dir | str or Path | ".agents/skills" | Directory containing skill packs |
mcp_servers | list[MCPServerLike] | None | MCP server configs for external tool discovery |
fail_safe | FailSafeConfig | defaults | Step limits, cost budgets, timeout, and failure policies |
context_defaults | dict | None | Default JSON context merged into each run before caller context |
inherit_context_keys | list[str] | None | Context keys inherited from parent agent in delegation |
model_resolver | callable | None | Custom function to resolve model names to LLM clients |
instruction_roles | list[InstructionRole] | None | Structured instruction sections with role-based ordering |
policy_roles | list[PolicyRole] | None | Role-based policy rules applied during execution |
policy_engine | PolicyEngine | None | Policy engine for tool/action gating |
subagent_router | SubagentRouter | None | Custom routing logic for subagent delegation |
max_steps | int | 20 | Maximum agent loop iterations |
tool_parallelism | int | None | Max concurrent tool executions per step |
subagent_parallelism_mode | str | "configurable" | How subagent concurrency is managed |
reasoning_enabled | bool | None | Enable extended thinking / chain-of-thought |
reasoning_effort | str | None | Thinking effort level (e.g. "low", "medium", "high") |
reasoning_max_tokens | int | None | Token budget for extended thinking |
skill_tool_policy | SkillToolPolicy | None | Security policy for skill-provided tool execution |
enable_skill_tools | bool | True | Whether to expose skill tools to the agent |
enable_mcp_tools | bool | True | Whether to expose MCP-discovered tools to the agent |
runner | Runner | None | Pre-bound runner instance (advanced usage) |
Single agent vs multi-agent
- Single agent
- Multi-agent
A single agent handles everything. Best for focused tasks.Use when: The task is well-defined and doesn’t need specialized sub-expertise.
How subagent delegation works
When an agent has subagents, AFK automatically generates transfer tools (transfer_to_researcher, transfer_to_writer). The coordinator calls these like any other tool.
Each subagent runs a full agent loop with its own model, instructions, and tools. The coordinator sees only the subagent’s final_text.
Adding safety limits
Every agent should have aFailSafeConfig in production:
Policy-aware agents
Attach a PolicyEngine to control what the agent can do:allow (default), deny, request_approval (human-in-the-loop), or request_user_input.
Design guidelines
- Start with one agent. Only add subagents when you have clear evidence that the task needs specialized expertise.
- Keep instructions focused. Vague instructions produce vague results. Tell the agent exactly what to do and what not to do.
- Use typed tools. Every tool argument should be a Pydantic model. Untyped arguments bypass validation.
- Set cost limits early. Add
FailSafeConfigbefore your first deployment, not after your first runaway bill.