How agentic workers work

The difference between a chatbot and a colleague is discipline: memory that carries between conversations, a process the agentic worker follows the same way every time, and judgment about when to act versus when to ask. This page explains the operating traits every awk (agentic worker) brings to the work — where each one stops, and what you, managing the software factory they work in, do beside them.

That is also why it works the same way whoever on your team assigns the work: the awk follows the same workflow, picks the model for each step within your team's settings, and manages its own context.

Memory

Auto memory

Agentic workers recall the context that matters at the start of every turn, and save what's worth keeping so it persists between conversations and sessions. You tell the team something once — a convention, a preference, a constraint — and you don't have to repeat it. Recall is automatic; saving is deliberate, so the memory stays a curated set of durable facts rather than a transcript of everything ever said.

Decision records

When an agentic worker makes a consequential, non-obvious choice, it records the decision, the reasoning behind it, and the alternatives it weighed — linked to the evidence (work items, PRs, prior findings). These records are pinned durably, so when a long thread is compacted the why behind a choice is recalled exactly later, by the same agentic worker or by a teammate resuming the thread, instead of being vaguely reconstructed.

Decision records capture the choices an agentic worker judged consequential — not a verbatim transcript of the whole conversation. They're a precise, structured record of what was decided and why.

Team memory

A learning one colleague captures is available to the whole team. When one agentic worker works out how your repo is laid out, which reviewer owns a service, or how you like PRs structured, that knowledge is there for every agentic worker on your team — so patterns stay consistent across everyone's work. Team memory is scoped to your team; it is never shared across tenants.

Discipline

Set workflows

Agentic workers work role-specific checklists end to end — the same way every time, the way an experienced engineer follows a runbook. The engineer gathers requirements, plans, gets the plan reviewed, implements, reviews the code, and only then opens a PR. QA runs its own checklist: it turns the requirements into test cases, tests the feature, captures the findings and artefacts — screenshots and screen recordings — and hands the work back with those findings when something needs fixing. The steps don't get skipped because the agentic worker is in a hurry.

Gated actions

Actions that are irreversible or reach outside your team need your explicit approval before they run: opening or merging a pull request, pushing to main (or master) or force-pushing, sending an email or message to another person, or changing what a file or document is shared with. Merging, pushing to main and force-pushing are approved one at a time, every time. For the others, a person in the thread can choose to approve all of that kind; later actions of that kind in that thread then go ahead without asking again, until the work closes or seven days pass, whichever comes first. Ordinary pushes to the agentic worker's own working branch and routine status moves on the assigned work item are part of the normal flow and don't stop to ask. The agentic worker proposes the action; you approve or hold it. The gate is fail-closed: when it is unclear whether an action needs approval, the action is not run. This is containment by design: routine, reversible work flows without friction, and the consequential steps wait for a human — you approve or hold them right in the Slack thread the agentic worker is working in.

Autonomy dial

You set how much the agentic workers lean on you versus the active awk for the judgment calls — the "should I do it this way or that way?" moments — across a five-position dial, from always ask you through balanced to the team decides. The default leans toward the team, so you're not consulted on every small fork, but you can turn it all the way toward yourself.

The dial is advisory: it changes who is asked about a decision, not what an agentic worker is allowed to do. It never widens an agentic worker's authority — irreversible and outward-facing actions still need a person's approval regardless of where the dial is set (see Gated actions above).

Your role

Awks work without you, and with you whenever you choose. What the people managing the factory do comes in three parts.

Assign

You write the work item the way you would for any developer and assign it, from Jira or by asking in Slack. When something is unclear the awk asks a short batch of questions up front and waits for your answers. By default the developer awk then posts a plan — with an architecture diagram for anything non-trivial — and reworks it with you as many times as you need. It doesn't build until you approve. After that the plan is fixed; a material change of scope needs a new approval.

Step in

• →Ask where it's up to in the thread, or ask Oracle what OG and QA are working on.
• →Pause and redirect. Say stop or wait and the awk pauses where it is and keeps its progress; tell it what to do instead, or say resume. cancel is different: it discards the work, after a confirmation.
• →Change the requirement by telling the awk in the thread; it adds the work to its plan and asks you to approve a real change of scope. An edit made only in Jira after pickup is not noticed.
• →Ask it to prove something. It runs the check, records the result with evidence, and shows you.
• →Push your own commits to the awk's branch; its next sync merges them instead of overwriting them. Tell it in the thread when you've pushed — it isn't notified of a push or a pull request comment.
• →Test with it. Add to the QA awk's test cases by telling it in the thread and ask for a re-run. Take the platforms only a person can access — a real device, a system behind your VPN — and the awk tests what it can reach: it drives your running app in a headless browser, calls your APIs, runs scripts and tests, and captures screenshots and video. Report what you found in the thread. With a read-only grant on your cloud logs, do the action, tell it, and it pulls your service's log entries from that window.
• →Show it how your team tests by uploading a skill to the thread.

Anyone on the team's access list can work with an awk in the same thread, including approving its plans. Back-and-forth uses credits like any other awk work; the cap on a single work item stops one from running away.

Approve

The gated actions above need a person wherever the dial sits. Merging a pull request, pushing to main and force-pushing wait for your approval every time; opening a pull request and posting outside your team wait too, unless a person on your team in the thread has chosen to approve all of that kind. You approve or hold them in the thread. What the plan is, what the pull request contains and whether it ships are your decisions; the hours in between are the awk's.

For the shape of a whole initiative — how many work items run at once, and where to see what each one cost — see Running an initiative.

Scale & economics

Model router

Not every task needs the most powerful model. A built-in router matches each task to the most economical model that can do it well: the work is sized up before it starts, and heavier models are reserved for the work that actually earns them. You get frontier-grade results on the hard parts without paying frontier prices for the routine ones.

Subagent fan-out

For a large job, an agentic worker decomposes the work into subtasks and runs them in parallel rather than grinding through serially — reading several parts of a codebase at once, or implementing independent pieces concurrently. A work item's subtasks run inside it, so they count as one active work item against your plan; how many run at once is set by the platform, not by your plan.

Context management

Long-running work would balloon an agentic worker's context if left unchecked. The agentic worker keeps only the context that's still relevant and compacts the rest, so the working window stays small. That keeps every turn fast and economical — and is part of why economical models can deliver senior-level results.

Re-expandable history

Compaction here isn't a one-way squash into a lossy summary. When older work is compacted, each step that was set aside stays retrievable, so the agentic worker can re-expand the exact original detail on demand when a later decision needs it, instead of working from a blurred paraphrase. The window stays small day-to-day, but the full detail is a step away when it matters.

Cost per work item

Every work item freezes the credits it consumed when the work completes, and posts the total back to you, so you can see what a given piece of work actually cost. Credits are billed at a fixed rate — see Billing & credits for the current price per credit and how consumption works.

In the console, an account owner can see what each work item cost in the Sessions & Work Items tab under Analytics, and open one to see its usage turn by turn.

Rapid startup

To verify a change, agentic workers don't just reason about it — they spin your service up and check it actually runs. That's the difference between "this should compile" and "I ran it and here's what happened." See Preview links & localhost access for how you can watch a running service yourself.

Multimodal input

Agentic workers read more than text. Attach an image, a PDF, or an audio clip in a thread and the agentic worker works from its contents directly; video is supported on request as an opt-in per team. See Attachments / rich media for the supported types, size limits, and per-team controls.