Agents and Assistants
The two flavors of AI agent in Project88 — when to use which, what they share, and what's different.
Project88 has two flavors of the same underlying primitive. You pick the type at creation time, and you can upgrade an Assistant to an Agent later without losing any config.
Assistant — Role + Soul
A conversational AI defined by its identity, model, tools, and optional sub-agents. The LLM decides at runtime when to call a tool or delegate to another agent.
| Aspect | Behaviour |
|---|---|
| Create flow | Type picker → Template → Name / Model / System Prompt → Done |
| Edit tabs | Role, Soul, Config (no Flow tab) |
| Tool use | LLM decides per turn based on tools.allow / tools.deny |
| Sub-agent calling | LLM decides — driven by subagents.allowAgents |
| Use cases | Customer support, coding assistant, research analyst, internal team bot |
Pick an Assistant when the conversation itself is the workflow — you don't have predetermined steps, you want the model to reason and act.
Agent — Role + Soul + Pipeline
Everything an Assistant has, plus a visual pipeline drawn in the Automation editor (React Flow). You define the exact graph of nodes; the runtime executes it in order.
| Aspect | Behaviour |
|---|---|
| Create flow | Type picker → Template → Name / Model / System Prompt → Done → Open Flow editor |
| Edit tabs | Flow, Role, Soul, Config (Flow is primary) |
| Tool use | Explicit Tool Call nodes in the pipeline |
| Sub-agent calling | Explicit Delegate nodes — you choose when and to which agent |
| Pipeline storage | pipelineNodes + pipelineEdges jsonb on the agents row |
| Use cases | Call handler, SMS campaign, lead qualifier, multi-step data pipeline |
Pick an Agent when you need determinism — the same input should produce the same shape of execution, and you want to inspect the graph rather than reason about LLM-driven control flow.
What they share
Both types live on the same agents table and share the same fields:
- Identity — system prompt, model, icon, accent color, description.
- Role —
tools.allow/tools.deny(allow/deny lists across the 12+ built-in and Composio tools),subagents.allowAgents. - Sandbox — execution mode and scope (planned controls for read-only, workspace-scoped, etc.).
- Config — name, ID, accent, workspace, agent type, template linkage.
The single discriminator is agent_type:
agent_type: 'assistant' | 'agent'; // default 'assistant'
pipeline_nodes: PipelineNode[]; // populated for 'agent'
pipeline_edges: PipelineEdge[]; // populated for 'agent'
pipeline_variables: VariableMap; // populated for 'agent'Upgrade path
From an Assistant's Config tab, click Upgrade to Agent. This:
- Sets
agent_typeto'agent'. - Initialises an empty pipeline with a single Start node.
- Adds the Flow tab to the modal.
Nothing else changes. Role, Soul, Config, and every existing tool / sub-agent binding are preserved. You can downgrade by deleting the pipeline (planned).
Templates
Both types are created from a template picker. The built-in templates are:
- Blank — empty system prompt, no tools, no sub-agents.
- Support Agent — customer support persona with research tools.
- Code Reviewer — code review persona with GitHub tools.
- Phone Agent — Telnyx-aware persona for SMS / voice.
- Outreach Agent — outbound campaign persona.
- Orchestrator — agent built to delegate to other agents.
Templates are operator-managed (service_role writes) and published org-wide. When the operator pushes an update, your overrides (custom name, accent, etc.) are preserved on the instance; the underlying behaviour evolves.