Jido Core
Foundational skill for the Jido agent framework ecosystem.
Jido Ecosystem
| Package |
Purpose |
Key macro/module |
| jido (core) |
Agent framework |
use Jido.Agent, cmd/2, directives, plugins, AgentServer |
| jido_action |
Composable validated actions |
use Jido.Action, schema, run/2 |
| jido_signal |
CloudEvents-based signals and routing |
Jido.Signal, Jido.Signal.Router |
| jido_ai |
AI/LLM integration for agents |
Jido.AI, tool-calling, prompt chains |
| req_llm |
HTTP client for LLM APIs |
Anthropic, OpenAI, Google, Ollama |
Core Design Principles
- Agents are immutable data structures — plain structs, no hidden state.
cmd/2 is the single entry point — actions in → updated agent + directives out.
- State changes are pure data transformations — actions receive params, return maps.
- Side effects are directives — typed descriptions executed by the runtime, never inline.
- Built on OTP — agents run as GenServer processes (
AgentServer) in production.
Project Structure Convention
my_app/
├── lib/my_app/
│ ├── agents/ # Agent modules (use Jido.Agent)
│ ├── actions/ # Action modules (use Jido.Action)
│ ├── plugins/ # Plugin modules extending agents
│ └── sensors/ # Sensor modules for external input
├── test/
├── config/
├── mix.exs
└── AGENTS.md
Elixir/OTP Conventions for Jido
- Always
use Jido.Agent with name, description, and schema.
- Define
signal_routes for runtime signal handling in AgentServer.
- Keep actions pure — side effects belong in directives.
- Use NimbleOptions schemas for all validation.
- Follow standard Elixir naming:
PascalCase modules, snake_case functions.
- Run
mix test and mix quality before committing.
- Prefer
@moduledoc and @doc on all public modules and functions.
Key Types
| Type |
Description |
Jido.Agent.t() |
The agent struct — immutable, holds state and metadata |
Jido.Instruction.t() |
Action + params tuple passed to cmd/2 |
Jido.Signal.t() |
CloudEvents envelope carrying event data |
Directive Types
| Directive |
Effect |
Emit |
Dispatch a signal to the bus |
Spawn |
Spawn a BEAM child process |
SpawnAgent |
Spawn a child Jido agent |
StopChild |
Stop a tracked child process |
Schedule |
Send a delayed message |
Stop |
Stop the agent process |
Quick Example
defmodule MyApp.Agents.Counter do
use Jido.Agent,
name: "counter",
description: "A simple counter agent",
schema: [
count: [type: :integer, default: 0]
],
actions: [MyApp.Actions.Increment]
signal_routes do
on "counter.increment", do: act(MyApp.Actions.Increment)
end
end
defmodule MyApp.Actions.Increment do
use Jido.Action,
name: "increment",
description: "Increment the counter by a given amount",
schema: [
amount: [type: :integer, default: 1]
]
@impl true
def run(params, context) do
current = context.state.count
{:ok, %{count: current + params.amount}}
end
end
# Usage
{:ok, agent} = Counter.new()
{agent, directives} = Counter.cmd(agent, {Increment, %{amount: 5}})
agent.state.count
#=> 5
Available Reference Docs
For deeper information, read these files:
reference/agents.md — Agent definition, schema, cmd/2, plugins, AgentServer
reference/actions.md — Action behaviour, run/2, schema validation, composition
reference/directives.md — Directive types, runtime processing, custom directives
Workflow
When working in a Jido project:
- Identify the package — which Jido library is involved?
- Check the agent — read the agent module for schema and actions.
- Trace through
cmd/2 — follow action → state update → directives.
- Run tests —
mix test for correctness, mix quality for lint/format/dialyzer.
- Load deeper skills — load package-specific skills (jido-actions, jido-signals, jido-ai) as needed.
1---2name: jido-core-23description: Jido ecosystem overview, conventions, and foundational patterns. Load this skill when working with any Jido package. Covers the ecosystem map, Elixir/OTP conventions, project structure, and core design principles. Use when asked about Jido, building agents, or working in a Jido-based project.4license: Apache-2.05---67# Jido Core89Foundational skill for the Jido agent framework ecosystem.1011## Jido Ecosystem1213| Package | Purpose | Key macro/module |14|---------|---------|-----------------|15| **jido** (core) | Agent framework | `use Jido.Agent`, `cmd/2`, directives, plugins, `AgentServer` |16| **jido_action** | Composable validated actions | `use Jido.Action`, schema, `run/2` |17| **jido_signal** | CloudEvents-based signals and routing | `Jido.Signal`, `Jido.Signal.Router` |18| **jido_ai** | AI/LLM integration for agents | `Jido.AI`, tool-calling, prompt chains |19| **req_llm** | HTTP client for LLM APIs | Anthropic, OpenAI, Google, Ollama |2021## Core Design Principles22231. **Agents are immutable data structures** — plain structs, no hidden state.242. **`cmd/2` is the single entry point** — actions in → updated agent + directives out.253. **State changes are pure data transformations** — actions receive params, return maps.264. **Side effects are directives** — typed descriptions executed by the runtime, never inline.275. **Built on OTP** — agents run as GenServer processes (`AgentServer`) in production.2829## Project Structure Convention3031```32my_app/33├── lib/my_app/34│ ├── agents/ # Agent modules (use Jido.Agent)35│ ├── actions/ # Action modules (use Jido.Action)36│ ├── plugins/ # Plugin modules extending agents37│ └── sensors/ # Sensor modules for external input38├── test/39├── config/40├── mix.exs41└── AGENTS.md42```4344## Elixir/OTP Conventions for Jido4546- Always `use Jido.Agent` with `name`, `description`, and `schema`.47- Define `signal_routes` for runtime signal handling in `AgentServer`.48- Keep actions pure — side effects belong in directives.49- Use NimbleOptions schemas for all validation.50- Follow standard Elixir naming: `PascalCase` modules, `snake_case` functions.51- Run `mix test` and `mix quality` before committing.52- Prefer `@moduledoc` and `@doc` on all public modules and functions.5354## Key Types5556| Type | Description |57|------|-------------|58| `Jido.Agent.t()` | The agent struct — immutable, holds state and metadata |59| `Jido.Instruction.t()` | Action + params tuple passed to `cmd/2` |60| `Jido.Signal.t()` | CloudEvents envelope carrying event data |6162### Directive Types6364| Directive | Effect |65|-----------|--------|66| `Emit` | Dispatch a signal to the bus |67| `Spawn` | Spawn a BEAM child process |68| `SpawnAgent` | Spawn a child Jido agent |69| `StopChild` | Stop a tracked child process |70| `Schedule` | Send a delayed message |71| `Stop` | Stop the agent process |7273## Quick Example7475```elixir76defmodule MyApp.Agents.Counter do77 use Jido.Agent,78 name: "counter",79 description: "A simple counter agent",80 schema: [81 count: [type: :integer, default: 0]82 ],83 actions: [MyApp.Actions.Increment]8485 signal_routes do86 on "counter.increment", do: act(MyApp.Actions.Increment)87 end88end8990defmodule MyApp.Actions.Increment do91 use Jido.Action,92 name: "increment",93 description: "Increment the counter by a given amount",94 schema: [95 amount: [type: :integer, default: 1]96 ]9798 @impl true99 def run(params, context) do100 current = context.state.count101 {:ok, %{count: current + params.amount}}102 end103end104105# Usage106{:ok, agent} = Counter.new()107{agent, directives} = Counter.cmd(agent, {Increment, %{amount: 5}})108agent.state.count109#=> 5110```111112## Available Reference Docs113114For deeper information, read these files:115116- `reference/agents.md` — Agent definition, schema, `cmd/2`, plugins, `AgentServer`117- `reference/actions.md` — Action behaviour, `run/2`, schema validation, composition118- `reference/directives.md` — Directive types, runtime processing, custom directives119120## Workflow121122When working in a Jido project:1231241. **Identify the package** — which Jido library is involved?1252. **Check the agent** — read the agent module for schema and actions.1263. **Trace through `cmd/2`** — follow action → state update → directives.1274. **Run tests** — `mix test` for correctness, `mix quality` for lint/format/dialyzer.1285. **Load deeper skills** — load package-specific skills (jido-actions, jido-signals, jido-ai) as needed.