What each can reach
All three can also search the web and read pages (an API’s reference, your site).
Each CoPilot is handed a fresh snapshot of its subject before every model call — for
AgentCoPilot, the whole draft, its attached tools, and an inventory of the workspace’s
tools, secret names, configured providers and webhooks — so it does not need reads to get
started.
Boundaries between them: ToolCoPilot and TaskCoPilot cannot write agents; TaskCoPilot
cannot create or edit tools or FAQ entries. If something they need does not exist yet, they
tell you where to make it.
Not reachable by any CoPilot (or the MCP server): sign-in, workspaces, members, roles,
personal access tokens and the retention setting; billing; playing or deleting recordings;
deleting a call, chat or outbound batch; chat browser tokens; the SSE streams (it polls
instead); CoPilot chat endpoints. AgentCoPilot also cannot send or resume a WhatsApp batch.
See MCP permissions.
Rules they follow
- Edit only the open subject. “Build me a support agent” configures the agent you have open (and may rename it). A second agent, tool or task is created only when you ask, or when AgentCoPilot needs a handoff target. It never deletes the subject you are in.
- Never publish unless asked. Publishing the agent or task waits for “publish”, “deploy”
or “go live”; TaskCoPilot runs
validate_taskfirst. In ToolCoPilot, publishing the tool is also your call. AgentCoPilot may publish a tool without asking, since attaching requires it. - Never reach a real person unless you named them — no outbound call or message to a contact it picked.
- Delete only on an explicit request naming the target. Unassigning a phone number is treated the same way.
- Never repeat a secret value. It reads secret names, never values; create the secret yourself and tell it the name.
- Validate rather than assume. It reports only validation results it got from the server.
- Ask before side effects. Tool and task test runs execute for real; it runs read-only ones freely and asks before one that books, charges, sends or deletes — a judgement made from the URL and method, so say if something is expensive.
- TaskCoPilot tests with
run_taskontask_version: "draft"instead of publishing.
Cost
The CoPilots are never billed. They run on Talqing’s own model and keys, open no session and do not appear on your ledger. What they run is billed normally: a tool test run, arun_task, an outbound call you asked for, and everything your published agents
then handle.
Prompting
Describe behaviour, not fields, and give it the facts it cannot look up:Build an order-status line for Example Retail. Ask for the order number, look it up athttps://api.example.com/orders/{order_id}with theORDERS_API_KEYsecret, read the status back plainly, and hand off to Billing if the caller asks about a refund.
The tool should look up a booking by reference:GET https://api.acme.example.com/bookings/{ref}withAuthorization: BearerfromACME_API_KEY. It returns{booking: {date, time, table_size}}. Read the date and time back and ask if they want to change it.
Run it with priya@northwind.example and tell me why it left the headcount null.
- For tools, say whether a value goes to
tooldataoruserdata,sayorgenerate_reply, and what happens on error (on_error); otherwise it picks and tells you. - For tasks, give the standard for each output value — it ends up in the field description, which is the prompt for that value.
- Make one change at a time on something that already works, and ask it to validate.
- When debugging, point at evidence: a call id, a run id, a number. It reads transcripts, tool calls, timings and cost.
Limits
Next
Versions
What the CoPilot’s draft edits wait on.
Build from your terminal
The same operations from Claude Code or Codex.