Tell me what this task should work out and I’ll build it — the prompt, the values it takes in, and the fields it has to produce. Saving is live here; there is no publish step.That is not a pleasantry. The AgentCoPilot and the ToolCoPilot leave a draft behind for you to publish; this one does not. Every change it makes is live on the next run.
What it can reach
There are deliberately no tool writes on that list. A task’s tools are built in the tool editor, where ToolCoPilot lives and where a tool has a test panel and version history. When your task needs a tool, a secret or an integration that does not exist yet, TaskCoPilot will say so and tell you where to make it, rather than offering to do it from here.
It cannot change anything else in the workspace either: no agents, no knowledge bases, no provider keys, no integrations.
What it is good at
Two things in this editor are genuinely hard, and they are what it is pointed at. An output worth extracting. Every field is one flat scalar with a description that is the prompt for that value — so the difference between"Company name" and "The company's legal or trading name, as it appears on their own site. Send null if the domain resolves to no company you can identify." is the difference between a field you can trust and one you cannot. It will push toward a handful of sharply described fields rather than a dozen vague ones, and it knows that five talking points is one string, not five fields. See inputs and output.
A prompt that reliably finishes. It knows the submit_result paragraph is generated and will not write a copy of it into your prompt, and it knows the fix for a no_output run is the prompt while the fix for a step_limit run is a number in Limits. Ask it to read a failed run before you ask it to change anything.
How to prompt it
- Say what the task should work out, not how to configure it. “Research a company from a work email and write me an opening line” gets you a prompt, the input, and the output fields. “Set output[0].name to company_name” gets you one field.
- Give it the standard for each value. “The subject line has to be under 60 characters and name the company” ends up in the field description, which is the only place it can do any good.
- Ask it to run and then read the trace. “Run it with priya@northwind.example and tell me why it left the headcount null” is a better instruction than “make it more accurate”.
- Name things by name. Tools, integrations and secrets are in front of it by name; it does not need ids from you.
- Ask before anything with a side effect. A run executes for real. It will run a read-only research task freely and ask first for a task that books, charges, sends or deletes — hold it to that.
Limits
- 25 model round-trips per turn. A long build stops with “I hit my step limit for one turn” and picks up where it left off when you tell it to continue. Partial progress is kept, because each write landed as it happened.
- It acts as you, with your role. Everything it does is inside your workspace and inside your permissions. Sending it a message needs the editor role; a viewer can watch the conversation but cannot make it write.
- It is never billed. TaskCoPilot runs on Talqing’s own model keys, not on the provider keys your agents and tasks run on, and it produces no session and no charge. A
run_taskit fires does spend your tokens — that is the task running, not the CoPilot. - One task per conversation. It edits the task whose editor it sits in.
- It cannot undo. There are no task versions, so an edit it makes replaces the previous wording with nothing kept. If you are attached to a prompt, copy it somewhere before you ask for a rewrite.
Next
AgentCoPilot
The same builder in the agent editor, where a draft and a publish exist.
ToolCoPilot
Where a task’s tools actually get built.