Running an initiative
Break an initiative into work items, choose how many run at once, see what each one cost in the console, and approve what ships.
An initiative is a backlog of work items, and your software factory works through it: awks (agentic workers) — AI developers and testers — build and test each one, your engineers and QA manage the work, and every work item carries its price. This page is how to run one, from the first work item to the last approval.
1. Break it into work items
Write each work item the way you would for any developer: what it is, what done looks like, and how you'll check it. Work that is scoped and self-contained — a bug fix, a small feature, a test-coverage pass, a refactor of one module — moves cleanly from work item to pull request. Break a large piece into several.
Where the work items live is up to you. Jira is optional: a work item can be a Jira Cloud ticket you assign with a field or a label, or a request you make in Slack by mentioning the awk. Either way the developer awk opens a Slack thread on it and confirms the requirements with whoever wrote it when something is unclear.
2. Choose how many run at once
Your plan sets how many work items can be active at the same time:
| Plan | Active work items |
|---|---|
| Starter | 5 |
| Growth | 25 per team |
| Scale | 100 per team |
A work item is active while a developer or tester awk has it queued or in progress, including while it waits for your answer or approval. Questions you ask the other awks don't count.
Assign the whole initiative and the awks work through it at your plan's
capacity: a Jira ticket assigned while the team is at its limit stays where
it is and is picked up when a slot frees. To free a slot yourself, say
wait or stop in a work item's thread: it pauses where it is, keeps its
progress and no longer counts; say resume to continue it. (cancel is
different: it discards the work, after a confirmation.)
If you consistently hit the limit, the next plan is the way to raise it; see Billing & credits.
3. See what each work item cost
Credits are metered on each work item as the awks work it, and the total is posted back to you in the thread when the work completes. In the console, an account owner can see every work item's cost in the Sessions & Work Items tab under Analytics, and open one to see its usage turn by turn.
The Initiatives tab beside it adds them up for you: it groups work items by their Jira epic, or by the initiative an awk linked them to, and shows what each initiative has cost so far, with how many of its work items are done and active. Workspace owners see every team; team admins see the teams they administer.
Two things to know about that figure: it is the awks' metered usage, not your people's time; and any one work item can run above the typical ranges on the pricing page. To keep one from running away, an owner can set a cap on a single work item: a work item that reaches it pauses and asks before spending more.
4. Approve what ships
Your team decides what is built and whether it ships. By default the developer awk posts a plan and builds once you approve it; merging a pull request waits for a person's approval whatever your other settings, and opening one does too unless a person on your team in the thread has chosen to approve them all; and acceptance in your own UAT is yours. In between, step in as much or as little as you choose — ask where it's up to, change the requirement in the thread, test with it — see Your role.
What to read next
- →How agentic workers work — the operating traits behind every awk, and your role beside them
- →Billing & credits — plans, credits and the cap on a single work item
- →Quickstart — from sign-up to a working factory in about fifteen minutes