Agents

An agent is a specialized AI worker. Instead of one general assistant, Erdo gives you a team you assemble from a gallery and brief in plain language. You tell an agent the outcome you want; it connects to your data, does the work, and reports back — asking before anything consequential. Each agent has a profile — its identity, what it knows and who wrote it, where it’s deployed, and its history. Open it from the agent’s conversation: click the agent’s name or avatar in the conversation header. From there you can view the agent’s knowledge and history. Organization administrators with edit access can edit, share, rename, roll back or delete agents owned by their organization. Agents shared from another organization remain readable and show their owner; management controls stay hidden when ownership is unknown.

​

Recruit an agent

Open Home → New conversation to talk to an enabled built-in agent or an existing custom agent. Organization administrators can choose Recruit an agent to browse the gallery, organized by area (marketing, sales, e-commerce, personal assistant, and more). Each agent describes what it’s good at and which connections it needs.

​

Build a custom agent

When no standard agent fits, choose create a new agent in New conversation and enter its name and role. A custom agent takes:

• Instructions — what it should do, how to behave, what to prioritize.
• Reference documents — files it should always have on hand.
• Pinned skills — reusable skills it can call.

Custom agents keep a version history, so you can change instructions freely and restore a previous version if a change doesn’t work out.

​

One agent, many deployments

An agent is the durable worker: its name, instructions, knowledge, skills, and run history live in one place. A deployment is a way for people to reach that agent. The same agent can work in Erdo, talk on a phone call, or appear on a website through chat, voice, and video without becoming several disconnected copies. Open Agents → Deployments to see every website, voice-runtime, and phone deployment. Website deployments own only channel settings such as greeting, voice, appearance, allowed origins, usage limits, and meeting scheduling. Edit the agent to change its name or instructions; every attached deployment picks those changes up automatically. External website visitors can search only knowledge your organization has explicitly marked Public — an agent’s private memories and internal skills are never exposed just because it is deployed.

• Choose Website to attach an existing agent to an embeddable chat, voice, or video surface. See Website Widget.
• Choose Voice or phone to open a guided chat that casts the voice and can assign a dedicated inbound number. See Voice Calls.

Deleting a deployment leaves the agent intact. Deleting the agent disables its attached deployments.

​

Configure and teach

Every agent has a Knowledge panel where it accumulates what it learns about your business — useful findings, known limitations, and optimizations — and reuses them on future runs. See Knowledge for how this works across your workspace.

​

When a run reaches its work limit

Agents have a limit on how many model turns one run can take. If work is still unfinished when that limit is reached, the run records max_iterations and is marked failed. It may still provide a summary of completed work and what remains; that summary does not mark the task complete. A final answer that finishes on the last allowed turn remains a successful run.

​

Recovery and access

Interrupted runs and approval continuations keep the credential restrictions and project selection that started them. Recovery verifies the original credential is still active, its configured capabilities and resource scopes are unchanged, and its original lifetime has not expired. Resource access is checked against current permissions each time; later resource sharing remains governed by your workspace’s current access rules. Revoking a credential, changing its configured restrictions, removing required membership, or deleting its owner can prevent recovery. Automatic recovery records the reason on the run; a manual continuation reports an actionable API error before starting execution. A temporary verification failure can be retried. Start a new explicitly authorized attempt after an access refusal; approving an action does not replace the original run owner’s identity. Recovery also needs a supported durable credential identity. Older runs without that record, guest and OAuth authentication without a supported durable lookup, and browser sessions whose provider lifetime could not be verified can execute fresh work but cannot be recovered automatically. Very large credential grant configurations also remain valid for fresh work but may exceed the supported recovery size; these runs report an explicit recovery refusal. Browser-session recovery uses the active provider session’s original lifetime, rather than extending a short session JWT’s expiry.

​

Choose the model

Agents pick the right model for each task on their own — a quick lookup runs on a fast model, a page build on a strong one. When it matters, you can also choose: say the model in the conversation (“build this page with Claude”, “generate three versions and use a different model for each”) and the agent pins it for that piece of work. The model it used is recorded on every run, so you can see which model produced which result and compare them side by side.

​

What agents can do

Agents use tools to act: query a dataset, run code, search the web, build a page, send an email, or place a phone call. They choose the tools a job needs — you don’t wire them up. Anything that changes your data or reaches outside Erdo goes through review and approval.

​

Seeing what a run used

A long piece of work — a multi-page build, a campaign setup — is rarely one agent acting alone. The agent you are talking to follows skills (reusable playbooks) and hands parts of the job to specialist agents, and the conversation says so as it goes, so you can tell what is driving a step before you decide whether to steer it:

• Loaded … at the top of a reply lists the skills, memories, datasets and integrations the agent brought into that turn. Expand it and click a skill to read the playbook. When multiple sources return the same Knowledge record, the agent includes it once in its injected context. Selected instructions take priority over an optional search copy. Run usage records selected bodies and skill references. Large searched playbooks may appear as skill references: their titles and read links are available, but their full instructions have not been loaded. Run details label these Reference only — body not loaded. Optional context that does not reach the agent is not listed as loaded.
• With the dqa_brand_brief_context rollout enabled (staff first), chat loads the approved brand brief for your offering as required context. When disabled, chat keeps its existing search and selected-reference behavior. Project attachments, page bindings, and page records that link to a brief select the relevant brief; when several briefs cannot be distinguished, all appear as references for the agent to read before acting. Large briefs load their Verified facts and Positioning sections, with a reference to the full brief. A reference or partial brief does not satisfy the full-read requirement for paid-media actions. If those sections are missing or too large to load completely, the brief appears as a reference for the agent to read. When the offering is unknown, a single brief loads automatically only if it has no project or page binding, offering-specific scope, or project attachment. A bound brief remains a reference until the offering is matched.
• A Skill card appears in the conversation when the agent picks up a skill mid-turn, naming it and linking to it.
• A specialist agent appears under its own name. When the agent hands work to another — “Growth Engineer”, “Data Analyst” — that agent’s steps show under its name, both in the collapsed summary of the turn and in each step as it runs.
• Run details, in the menu that appears when you hover a reply (next to Ask for help), opens the full record of that run: every skill it used and how it reached the run, the memories and definitions it drew on, and the tool evidence behind the answer. The same record is available over the CLI and API.

If a reply mentions a check or a step you did not ask for, the skill card or the run’s Skills and references list is usually where it came from. Before requesting approval for paid-media build actions, the agent must read the required campaign and copywriting playbooks and the approved brand briefs listed for your organization, when any exist. Action discovery supplies the Knowledge IDs to read. If a read is missing, the agent receives a correction before an approval card is created; it can read the named objects and retry. Selected instructions loaded in full also satisfy this requirement, and completed reads survive an approval pause. Creating a campaign or ad group needs the campaigns playbook and the copywriting skill; writing ad copy, keywords, targeting or assets needs the copywriting skill. Read-only actions, enable/pause operations, budget or bid changes and negative keywords do not require these playbook reads.

​

Tool call failures

If an agent produces incomplete or malformed tool arguments, the call fails without running the tool. The agent receives an error so it can correct the arguments. A tool failure does not establish that work was saved or completed. This includes streamed arguments cut off at the response’s output limit. A corrected attempt must send a complete argument object and stays within the run’s configured limits. If the agent cannot correct malformed input after two attempts, it stops with that cause recorded on the failed run. A closing summary does not turn the failed tool work into a successful result.

​

Quality reviews

A quality review needs the actual answer, code or resource evidence to inspect. Giving the checker only a question does not establish that an answer was reviewed. Workflows that call the Data Quality Checker should pass review criteria as query and the exact proposed answer and its evidence as output in a JSON input. Use mode: "holistic" to review a complete answer. For an independent prepared review, also set context_mode: "isolated". The reviewer starts without inherited conversation or Knowledge instructions. Include every applicable business rule in query and supply the exact material and source evidence to review. Explicit previous_feedback remains available and is rechecked against the current evidence. Omit context_mode to retain inherited context, including business definitions used by analytical reviews. The only supported explicit value is "isolated"; other values, including null or an empty string, fail before a model call. This option works with holistic and diagnostic reviews. The artifact critic and pairwise judge always start with fresh context. Their callers supply the review rubrics, criteria and work explicitly. Artifact lenses that review rendered images receive their rubric and screenshots without the writer’s brief or source code. A missing or malformed review result is a failed check. It cannot establish that no issues were found. A completed review with an explicit empty issues array means the reviewer found no issues in the material it received; it is not an approval to send a message or act on the result. For internal agent delegation, provide exactly one of input or input_content_slug. Use the actual stored-content slug returned by a tool when passing a large body. The agent loads its complete content before applying the same dispatch and required-input checks. The returned input_sha256 is computed from the exact bytes supplied to the agent. A holistic quality review accepts at most 64,000 characters of output and reviews it in full. Larger output fails before a model call; select the relevant evidence and request another review. Other diagnostic reviews retain their normal output preview limit. Holistic mode checks the complete answer against every supplied criterion on every revision, including prose-only claims and factual assertions in source summaries. Those assertions are checked against the underlying supplied source content. It preserves decision-quality checks for the primary metric, denominator, comparable windows, contradictions, and source gaps versus unsupported claims. It also checks that measurement fields are identified truthfully, budget controls are not presented as prices, and temporal estimates are not presented as current facts. Previous feedback is rechecked against the supplied evidence. Fixing one finding does not clear the complete revised answer. The Security Checker also treats missing code or malformed verdicts as failed checks. An empty issue array clears a check only when the complete verdict is valid; incomplete issue entries cannot be silently discarded. Page reviewers and evaluation judges also reject array-shaped verdicts, even when surrounded by prose. A complete object wrapped in ordinary prose remains supported. Evaluation judges require the criteria, score and reasoning before a result can be counted as a completed evaluation.

​

Verify source receipts

When a workflow passes source_receipts, each item must contain the complete thread_id, receipt_id, created_at, name, status, input, and result from a visible stored thread tool result. The checker re-reads the thread with the caller’s normal view permission before calling the model. It rejects a receipt if the stored content ID, server timestamp, tool name, status, input, or result no longer matches. Duplicate references are rejected. It accepts at most ten distinct receipts and a 64,000-character serialized evidence body. Verified receipts are included in the review context and reported as verified_source_receipt_count. This proves what the stored tool returned at that time; it does not prove claims made by an external website. Synchronous invoke_agent receipts include the actual agent_key selected by the tool. This identity and the run metadata are assigned by the runtime; agent-written output cannot replace them.

​

Stop a running invocation

Use erdo agent cancel <thread-id> or POST /v1/threads/{thread-id}/cancel-invocation with the invocation you are stopping in the body: {"invocation_id": "<invocation-id>"}. Read the thread owner’s latest durable invocation_id from GET /v1/threads/{thread-id}/completion-status; unlike the reused run row, this changes when an approval resumes. The CLI performs that read for you, or takes --invocation <id>. The caller needs edit access to the thread; scoped API keys need agents:run. If the thread has already moved on to a different invocation (someone else started a new run), the request is refused with a failed_precondition error whose details carry "reason": "invocation_changed", and nothing is cancelled. Read the thread’s completion status before deciding whether to cancel again. The response {"success": true} acknowledges that cancellation was propagated. Execution can still be winding down: read GET /v1/runs/{run-id} until its status is terminal. {"success": false} means at least one execution service could not acknowledge the request; the CLI exits with an error. Invalid thread IDs, missing threads, and insufficient access return the existing thread service’s errors. Closing a CLI polling command does not cancel its server-side invocation. In chat, Stop waits up to 15 seconds for the same root invocation’s persisted terminal state. If confirmation fails, a persistent cancellation error offers Retry cancellation. An acknowledgement or an idle connection never substitutes for that confirmation.