Agents & chatbots

The two kinds

Specialists are the autonomous agents. They have a heartbeat — they wake up every 30 seconds, check for assigned issues, and execute them. They use tools, write to the data store, leave comments on issues, collaborate with other agents, and mark work complete when they’re done. You create them, give them a job description and a tool set, and then you can walk away. A good specialist is one you can hand a project to on Monday and come back to Friday to find the work done.

Chatbots are interactive only. They wait for a user message, respond, and wait again. They have no heartbeat. They never pick up issues on their own. They never appear in the Project Manager’s auto-dispatch. They live in the /bots gallery, are embedded via the widget or the Bot API, and are designed for one-to-one conversations with end users — support, sales, FAQ, onboarding. A chatbot that’s waiting for its next message costs you nothing.

The same LLM can power either kind. The distinction is behavioural, not technical.

Anatomy of an agent

Both kinds share the same five building blocks:

1. Identity — a name, a display label, a one-sentence description, an icon. The description is what other agents see when the Project Manager is deciding who to delegate to, and what users see in the agent dropdown on the chat page. Write it like a job posting, not a biography.

2. Personality — the system prompt. This is the agent’s voice, its priorities, its rules. Good personalities are specific and opinionated: “You are a senior research analyst. You cite sources. You resist speculation. You write short paragraphs that lead with conclusions.” Bad personalities are vague: “You are helpful and friendly.” The personality is the biggest lever you have on quality.

3. Tools — the set of capabilities the agent is allowed to use. Web search, file system, shell, data store, task board, memory, send email, and more. You check boxes on the agent edit page. Tools not granted cannot be invoked, even if the agent decides it wants to. Grant the smallest set that lets the agent do its job.

4. Memory — every agent has persistent memory scoped to itself, plus access to project and system scopes. Memories are searched semantically on every turn and injected into the agent’s context as relevant. This is how a specialist remembers what happened in an issue it worked on last week.

5. Model — the LLM the agent routes through. Usually inherited from the instance default, but overridable per agent. Use a cheaper model for assistant-style bots, a larger model for agents that do deep reasoning.

That’s the whole configuration. Everything else (guardrails, budgets, tool restrictions, approvals) happens at the platform level and applies to every agent.

How they differ from a raw LLM call

A pure LLM call is stateless: you send a prompt, you get a completion, that’s it. An Exolvra agent adds four things that turn that stateless call into an agent:

• Durable workspace — when the agent uses a tool (saves a file, writes to the data store, posts a comment), the result persists after the conversation ends. Someone else can pick up where the agent left off.
• Multi-turn execution — the agent can call tools repeatedly, reason about intermediate results, and decide its next action. What feels like one completion to you is often ten internal turns.
• Cross-session memory — facts the agent learns in one session are retrievable in the next. Not a rolling conversation buffer — a searchable store of the agent’s own observations.
• Coordination — agents can send messages to each other, hand off work, and escalate up a hierarchy. The specialist you create today can be one node in a team of twenty tomorrow.

If you strip those four away, you have a chatbot wrapper around an API. Exolvra is the scaffolding that makes agents do real work.

Hierarchies

An agent can have a manager — another agent it reports to. Managers see the team structure in their system prompt and know who their direct reports are. When an agent receives a request that’s better suited to someone on its team, it delegates via sessions_send. When it gets stuck, it escalates up to its manager the same way.

A typical shape:

ceo
├─ vp-engineering
│  └─ tech-lead
│     ├─ frontend-dev
│     └─ backend-dev
└─ vp-product
   └─ product-manager

The CEO agent takes a high-level goal. It delegates engineering work down to the VP Engineering, which delegates to tech-lead, which delegates to the right specialist. Exceptions flow up the same chain in reverse. This is the hierarchical pattern — one of the seven coordination shapes covered in orchestration patterns.

You don’t need a hierarchy. Most small Exolvra deployments run a flat team of specialists under a single Project Manager. The hierarchy only earns its keep when you have enough agents that a flat team becomes noisy.

Creating new agents

There are three ways a new specialist comes into existence:

1. You create it manually from /agents/new. This is the normal path — you decide what specialist you need, write a personality, pick tools, save.
2. The Project Manager creates it on demand. When the PM is decomposing a goal and realises no existing specialist is a good fit, it can mint a new one itself. You’ll see a notification that a new agent was born; review and adjust if you don’t like the shape.
3. You clone an existing one from the agent detail page. Useful when you want a variant of a working agent with a different personality or tool set.

Chatbots only come from path (1) — they’re designed by humans, not spawned by agents.

When to use which

The rule of thumb: if it needs to work on its own, it’s a specialist. If it only responds when spoken to, it’s a chatbot.

Where to go next

• Your first agent — the step-by-step for creating one
• Agents — the dashboard reference for the agents page
• Bots — creating and managing chatbots
• Orchestration patterns — seven ways to coordinate multiple agents
• Tools, skills & MCP — how agents gain capabilities