How an agent works a task

Assigning a task to an agent feels almost too simple: you pick the agent as the assignee, and walk away. But a lot happens next, and understanding the mechanics turns the agent from a black box into a teammate you can actually direct. This page is the close-up — exactly how an agent works a task, where it does it, and how you stay in control the whole way through.

The short version: the task’s comment thread is the agent’s workshop. Everything it thinks, does, and asks happens there, in the open, where you can watch and steer.

Where the work happens: the comment thread

When you assign an agent to a task, the task’s comments become a live, two-way workspace. The agent doesn’t go off and do something invisible — it works in the comments, the same place your team already discusses that task. You read its progress like you’d read a colleague’s updates, and you reply to redirect it like you’d reply to anyone.

That’s the mental model to hold onto: assigning a task starts a conversation, and the agent drives it forward one comment at a time.

The execution loop, step by step

Here’s what actually unfolds once an agent is on a task. It’s a loop, not a single shot — the agent works, checks in, and continues.

It reads the task in full. Title, description, the “done” condition, custom fields, attachments, related tasks, and — importantly — any linked plan page. The clearer these are, the better it starts. (This is why writing a good task matters so much.)
It pulls in relevant context. Using the same retrieval that powers search, it gathers the knowledge it needs — its configured knowledge, related pages, prior discussion.
It posts a plan or first update. You’ll see a comment appear describing what it understands and how it intends to proceed. This is your first chance to course-correct.
It does the work, calling tools as needed. To actually do things — create a subtask, post a message, look something up in a database, call an external system — the agent uses tools. Routine, safe tools run on their own; sensitive ones pause for your approval (more below).
It asks when it’s unsure. If it hits a real decision or a missing piece of information, it doesn’t guess — it posts a question in the comments and waits for you.
It reports results and finishes. When the work is done, it posts the outcome. Depending on how it’s set up and what permissions it has, it may also move the task along its workflow — for example, into an “In Review” status so a human can check it.

Throughout, you can jump in at any point. A reply from you is just another comment in the thread — the agent reads it and adjusts.

What you’ll see while it works

Agent comments wear a status so you always know where things stand at a glance:

Status	What it means	What you do
Writing	The agent is thinking and composing.	Wait a moment — it’s working.
Waiting for User	It needs your input or approval to go on.	Answer its question, or approve/decline.
Completed	It finished this step and it’s ready for you.	Read it; reply if you want changes.
Failed / Canceled	Something went wrong, or the run was stopped.	Read the error, give context, or retry.

You’ll also see agentic steps woven into the thread — the agent quietly showing its work: the tools it called, the searches it ran, what it found. Expand them when you want to understand how it reached an answer; collapse them when you just want the result. This transparency is deliberate — you’re never asked to trust a result you can’t inspect.

Approvals: nothing sensitive happens without you

This is the part that should make you comfortable handing real work to an agent. Every tool an agent might use carries an approval policy:

Auto-approved tools — low-risk, reversible actions (reading a page, listing tasks, searching) just run, so the agent stays quick.
Approval-required tools — anything sensitive or hard to undo (sending an external email, deleting data, spending money) pauses and asks first. The comment goes to Waiting for User, and you approve, decline, or redirect.

You also control which tools an agent can see at all (tool visibility). An agent simply cannot use a tool you didn’t give it. Combined, these mean an agent operates on a short, clearly-marked leash — capable, but never running off.

A worked example

Say you assign a “Release Notes” agent to a task titled “Draft v2.4 release notes” with a linked plan page listing the shipped changes. Here’s how the thread might read:

🤖 Release Notes Agent · Writing…
🤖 I'll draft v2.4 release notes from the linked plan page. I see 6 merged
   changes grouped into Features, Fixes, and Internal. I'll write a short
   intro, then a section per group. Drafting now.

🤖 [agentic step ▸ read page "v2.4 — Shipped changes"]

🤖 Waiting for User
🤖 Two of the changes look internal-only (CI tweaks). Include them in the
   public notes, or leave them out?

🧑 You: leave them out, public notes only.

🤖 Writing…
🤖 Done — here's the draft:
   ## v2.4
   **Features** … **Fixes** …
   Want me to post this to #announcements, or open a page for review?

Notice the shape: it explained its plan, showed its work, asked instead of guessing, took your steer, and offered a clear next step — all in the comments, all reviewable.

Staying in control mid-flight

You’re never locked out while an agent works. At any time you can:

Reply with a steer — “make it shorter,” “use a formal tone,” “check the staging data first.” It adapts on the next turn.
Approve or decline a tool call when it’s waiting.
Cancel the run if it’s heading the wrong way, then re-assign with a clearer task.
Reassign the task to a person (or a different agent) — it’s a normal task the whole time.

Accountability: who did what

Everything an agent does is attributed. Its comments, the tools it called, the changes it made — all are recorded under its identity (when it acts on its own, it does so as a service account, which keeps the audit trail clean). You can always answer “who did this, and why,” which is exactly what regulated and security-conscious teams need. See Security & compliance.

Making a task “agent-ready”

Agents are only as good as what you hand them. A task an agent can run with usually has:

A specific title — “Draft v2.4 release notes,” not “release notes.”
A clear goal and “done” condition — what success looks like, stated plainly.
The context it needs — a linked plan page, relevant attachments, or pointers to the right knowledge.
The right tools and permissions — enough to do the job, no more (see least privilege).

If an agent seems lost, it’s almost always one of these missing. Add the context, narrow the task, or break it into subtasks, and try again.

When an agent gets stuck

It happens — and it’s usually quick to fix:

It keeps asking the same kind of question → the task is underspecified. Add the missing detail to the description or plan page.
It can’t do something → it probably lacks the tool or the permission. Check its tools.
Its answer is off → its knowledge may be missing or stale. Curate it.
A long run drifts → start fresh. Very long threads get summarized automatically (compaction), so a clean re-assignment with a tighter task often works better.

Agents in your workspace — the four ways agents join your work.
Tools & knowledge — what an agent can do and what it knows.
Knowledge that makes agents smart — set an agent up to succeed.
Tasks — the unit of work an agent picks up.