Skip to main content

What is an Agent?

An agent is the fundamental unit of deployment in klaw. It’s an autonomous AI entity that can:
  • Understand natural language instructions
  • Make decisions about how to accomplish tasks
  • Use tools to interact with systems and data
  • Maintain conversation context
  • Learn from interactions through memory
Think of agents like pods in Kubernetes—they’re the smallest deployable units that encapsulate the logic and capabilities needed to perform work.

Agent Architecture

Creating Agents

Using the CLI

Agent Definition File

Agents are stored as TOML files in ~/.klaw/agents/:

Agent Lifecycle

1

Creation

Agent definition is created and stored. No resources consumed yet.
2

Activation

When a message arrives for the agent, it’s activated with its LLM provider, tools, and system prompt.
3

Processing

Agent enters the tool-use loop: receive input → LLM decision → tool execution → repeat.
4

Idle

After completing a task, agent maintains conversation history but releases LLM connection.
5

Termination

Agent is deleted or cluster shuts down. History can be preserved or discarded.

Agent Properties

Agent Configuration

Per-agent settings in config.toml let you customize tool access, iteration limits, and approval requirements for each agent independently:
Tool filtering restricts which tools an agent can use. If tools is omitted, the agent has access to all registered tools. When specified, only the listed tools are available — the agent cannot call tools outside its allowlist. Approval gating requires user confirmation before specific tools execute. When a tool in the require_approval list is called, the user sees a prompt and must approve or deny execution.

Managing Agents

List Agents

Output:

Describe an Agent

Output:

Delete an Agent

Agent Communication

Agents receive work through channels:

CLI

Direct interaction via klaw chat

Slack

Messages in Slack channels/threads

API

REST API calls for programmatic access

Tasks

Dispatched tasks from controller

Multi-Agent Patterns

Specialized Agents

Create agents for specific domains:

Agent Spawning

klaw supports two forms of sub-agent creation: agent_spawn — Creates persistent agent bindings for the orchestrator. These are long-lived agents that can be routed to via @agent syntax. delegate — Spawns ephemeral sub-agents inline during a conversation. The sub-agent executes immediately, and its result is returned directly to the parent. This is the primary mechanism for multi-step task decomposition.
Use the delegate tool for inline sub-agents:
Or agent_spawn for persistent bindings:

Agent Runtime Modes

Agent runs as a local process with direct system access:
  • Full filesystem access
  • Direct command execution
  • Fastest performance

Best Practices

Give each agent a specific, well-defined task. Specialized agents perform better than generalists.Good: “API development and testing” Bad: “Do everything”
Only give agents the tools they actually need. Avoid granting bash access unless necessary.
Constrain agents to specific directories to prevent unintended file modifications.
Match model capabilities to task complexity. Use Sonnet for most tasks, Opus for complex reasoning.
Use max_session_cost to cap spending per session. Start conservative (e.g., $5.00) and adjust based on your workload. The agent stops gracefully when the budget is reached.
Add require_approval = ["bash", "write"] to agents that modify files or run commands. This adds a human-in-the-loop check before execution.

Next Steps

Tools

Learn about the tools agents can use

Skills

Compose capabilities with skills