Working with Gwen: how a job runs

You start with a request in plain language. Gwen's first job is to understand the outcome you actually want — not just the literal words, but the deliverable behind them.

From that, Gwen works out the shape of the job: the work area it belongs to, the likely deliverable, the skills and tools it will take, any connections that are missing, the risks, the approvals that will be needed, and a concrete first step. This happens before anything expensive runs.

Scoping protects you from vague, runaway work. You get to see what Gwen thinks the job is — and what it will require — before funding or execution begins.

That means no surprise about what a job entails: you know the plan, the connections it needs, and the rough weight of the work, and Gwen can recommend a Work Budget that fits. You approve the shape, then execution proceeds.

Gwen organizes work with a simple vocabulary, from smallest to largest:

• A skill is a single ability — something Gwen knows how to do.
• A task is one unit of work that uses skills.
• A workflow is a repeatable series of tasks.
• A mission is the goal: a concrete run that pulls together tasks, tools, and approvals to deliver an outcome.

Reusable collections of workflows can be packaged as playbooks. You do not have to think in these terms to use Gwen — but they are why repeated work gets faster: proven sequences become reusable instead of rebuilt each time.

A mission is the tracked container for a piece of work. It holds the status, the tasks, the artifacts produced, the context used, the approvals requested, the tool activity, your feedback, and the outcome.

Because everything is attached to the mission, work is never a black box. You can open a mission and see exactly what is happening, what is done, and what is waiting.

Every mission keeps a ledger: what Gwen did, what context it drew on, which tools it tried, which approvals are pending, and what it delivered.

This is how you stay in control without micromanaging. You do not have to watch every step; you can review the ledger to understand and steer. For teams, it is also the audit trail of how work actually got done.

Artifacts are the useful outputs of a mission — the things you came for. A brief, a draft, a plan, a summary, a code diff, research notes, a reply, a list, a report, a live preview.

Artifacts are reviewable and reusable. They are not buried in a chat transcript; they are first-class objects you can open, judge, edit, and carry into the next piece of work.

Under the hood, a typical job moves through a few stages: Gwen plans the work, executes it across the right engines and tools, independently checks the result, and then hands it back to you.

The independent check matters: where the work is high-stakes, a different model from the one that produced it can review it before you ever see it. The intent is that what reaches you has already cleared an honest bar, not just the builder's own opinion of itself.

Within a mission, Gwen can read, scope, draft, and prepare freely. But the moment a step would act on the outside world — send, publish, spend, deploy, change records, delete — it pauses for approval or follows a policy you set.

So a mission can run a long way on its own and still never take an irreversible real-world action without your say-so. See Approvals and control for the full picture.

Gwen tries to use sensible defaults and the context it already has, so it does not interrogate you over trivia. But when a real decision would change the outcome — a brand choice, a strategic call, missing access — it asks.

The aim is the right amount of friction: enough that the work matches what you meant, not so much that you are effectively doing the job yourself.

Because missions, artifacts, and memory persist, you can leave and come back. A job does not evaporate when you close the tab, and you do not have to re-brief Gwen to continue.

This is what makes longer, real work possible: a build, a research project, or a campaign can span days and sessions while Gwen holds the thread.