Works in Slack, GitHub and Jira
Stand up a software factory for your next initiative.
Your engineers and QA manage it. Awks build and test.
Awks (agentic workers) are AI developers and testers. There is a price on every work item, not on every seat, so you can see what the initiative is costing.
- A work item goes on the line. Set by one of your engineers, in Jira or by asking in Slack.
- The developer awk builds it. It asks its questions in Slack first; your engineers step in when they choose.
- The tester awk tests it. One case fails. 20 of 21. It goes back with steps to reproduce.
- Back down the line to the developer awk. Same work item, same thread.
- The developer awk fixes it. Second time round.
- Re-tested. 24 / 24. Ready for a person to approve.
- It comes off the line with its price. $27. Metered as the work ran. Your approval is the gate.
- The prices add up to what the initiative is costing. 13 of 20 work items so far. (Illustrative.)
The choice
A new initiative lands. Who builds it?
Reassign your team
Your own people build it, alongside or instead of their current work.
Hire or contract
People you hire or contract build it.
Bring in an agency
Another company builds it and hands it over.
Stand up a factory
Your engineers and QA manage it. Awks build and test each work item, a person approves what ships, and every work item carries its price.
Four ways to staff the same work. Not a comparison of cost or speed.
One initiative. 20 work items. Your team manages the factory.
Illustrative: an initiative of 20 work items on the Starter plan, 5 active at once. Awks build and test. Your engineers lead and co-architect. Your testers lead and co-test. Together, your team approves what ships and accepts it in UAT.
Backlog in.
Priced work out.
An initiative is a backlog of work items. Your engineers and QA run it through the factory with the tools they already use: a backlog, Slack and pull requests. Whoever on your team assigns a work item, the awk follows the same workflow, picks the model for each step within your team's settings, and manages its own context.
Break the initiative into work items the way you would for any team, then assign them in Jira or ask in Slack. Your plan sets how many are active at once. Setup is a single Slack install plus about fifteen minutes connecting your repos, and Jira if you use it.
The developer awk picks each work item up in a Slack thread, checks the requirements with whoever wrote it, then writes the code, runs the tests and puts it through a code review. Ask for independent QA and the tester awk checks it does what was asked, and sends it back if it doesn't. Your engineers and QA lead: they shape the plan with the awk and step in whenever they choose.
Each work item comes back with its evidence, a preview link to try it where there is an app to run, and what it cost. You approve what matters: a person decides whether it merges. The console adds up an initiative’s work items, so you can see what it has cost so far.
For engineers and QA
Engineers and QA become software factory managers
You set the work, step in when you choose, and approve what ships. The awks build and test. You already brief coding agents and read what comes back; this is the same conversation, with the workflow built in.
- You assign the work item and answer the awk's questions.
- Design it together: by default the awk posts a plan, reworks it with you, and builds once you approve it.
- By default, you approve the pull request before it merges.
- Step in whenever you want: ask where it's up to, change the requirement, ask it to check something. Say stop in the thread and it stops.
- If you test, test with it: add to the awk's test cases, ask for a re-run, and take the platforms only a person can access, such as a real device.
- The price is on the work item, not on you.
One real work item.
Start to finish.
DS-6 is a real Jira ticket on a Java backend. The developer awk picked it up in Slack, asked a person when something was unclear, built it and handed it over. The tester awk tested it, sent findings back, and re-checked the fixes. A preview link went into the thread for people to try.
- 01You· in Jira
- 02Developer awk· in Slack
- 03Tester awk1 bug found
- 03Tester awk24 of 24 pass
- 04You· preview link
- 05The receipt
Real screens from one run · click any to open it
The steps a work item goes through
From work item to done.
What always happens, and the two steps that depend on the work item. Independent QA is there when you ask for it; without it, the change comes to you after the AI developer's own tests and code review.
- Work item
You write it and assign it, the way you would for any developer: in Jira, or by asking in Slack.
- Picked up
The developer awk opens a Slack thread on the work item.
- Requirements checked
It asks whoever wrote it when something is unclear.
- Built and tested
It writes the code, runs the project’s own tests, checks the acceptance criteria and puts the change through a code review.
- Pull requestWhen the work item has a repo
Opening a pull request waits for your approval, unless a person on your team in the thread has chosen to approve them all.
- Independent QAOn request
A separate tester awk checks it against what was asked and sends it back if it finds issues.
- Ready for you
You get the change, its evidence and what it cost. A person decides what merges.
Why it matters
Your AI bill shows who spent it. Not what each work item cost.
Your AI bill, by person
IllustrativeEach figure equalsPer-seat fee≈ $100 · flatplusAI API tokensvaries by person
- A. Rivera$1,940
- J. Okafor$1,220
- M. Chen$410
- S. Patel$145
- Month total$3,715
- Spent on which work items?Unknown
Who used it. Nothing about what it delivered, or what else it paid for.
With AwkTeams, by work item
1 real · 7 illustrative- Item 1 · Checkout retry logic$34
- Item 2 · Invoice PDF export$21
- Item 3 · Search index rebuild$265
- Item 4 · Login rate-limit$18
- A real Jira ticket · Backend API · JavaBuilt · tested, 1 bug found · fixed · 24 / 24 passed · preview link · ready for your approval2,660 credits$27Real run · Jira ticket DS-6
- Item 6 · Audit log filter$48
- Item 7 · Permissions model overhaul$320
- Item 8 · Small fix$14
- Spent on which work items?Every dollar
What each work item cost, and what came back for it. Only the $27 row is a real figure: see that ticket, step by step → Two different things, not a price comparison: a team's AI bill on the left, a ledger of work items on the right. The ledger prices the work item, not the person who assigned it.
A price on every work item.
Your AI bill is metered to the person, not the work, so it can’t tell you what a feature cost. Here every work item is metered on its own: you see what each one cost in your console’s analytics, by session and by ticket.
Tests and code review built in.
On every work item that changes code, the developer awk runs the project’s own tests, checks the work against its acceptance criteria, and puts it through a code review. Then it pauses: you approve what matters, like merging a pull request. Want a second pair of eyes? Independent AI QA by a separate tester awk is there on request.
Safe to say yes.
Your awks read your code, write commits and move your work items along, so the controls are built in. By default a person is asked at two points on a work item that changes code: the plan before the build, and the pull request before it ships. How often you're consulted in between is a dial you set. Merging a pull request, pushing to main and force-pushing always wait for a person's approval, wherever the dial sits. Opening a pull request and posting outside your team wait for approval too, unless a person on your team in that thread has chosen to approve all of that kind; routine moves of the assigned work item through your workflow happen automatically, and every agent action is auditable.
Strong logical isolation per tenant. Each customer gets a separate database, credentials protected by per-tenant encryption keys (no key shared across customers), and separate per-team workloads, credentials, and audit trails. Every agent runs inside an OS-level sandbox with deny-by-default network egress, and a hard cross-tenant boundary keeps each customer's data, queries, and credentials inside their own tenant. The boundary is architectural, not a policy check — no prompt, tool call, or input can carry an agent across it.
Role-scoped agents with least privilege. Read-only roles (e.g. reporting/triage agents) are technically restricted from writing. Actions that are irreversible or reach beyond your team need explicit human approval. Merging a PR, pushing to main and force-pushing are approved one at a time, every time. Opening a PR and posting externally pause for approval too, unless a person in that thread has chosen to approve all of that kind. Routine bookkeeping on the assigned work item, like moving it through your workflow, happens automatically. Write access is scoped to the specific repositories you authorise.
Every agent action is auditable. Git activity, Jira changes, work item lifecycle, team administration, credential management — all logged with the context of the agent's task. Timestamped, team-scoped, exportable to CSV. Retention by plan, from 30 days up to 10 years.
Your code is never used to train models. We call frontier LLMs through commercial provider APIs — Anthropic, OpenAI, and Google — under business terms that prohibit training on your prompts and code, not consumer apps. Your code stays your code.
SAML 2.0 SSO on Scale and Enterprise; SCIM 2.0 user provisioning on Enterprise. Role-based permissions for admin access. Compatible with Okta, Google Workspace, Microsoft Entra ID, and other SAML 2.0 providers via standards compliance. Note: only your admins need AwkTeams accounts — engineers and PMs work with the agents through Slack, GitHub, and Jira using their existing identities.
Our hosting runs on Google Cloud Platform in Sydney, which is SOC 2 Type II and ISO 27001 certified; our Privacy Policy lists every other service that processes your data, and where. AwkTeams' own SOC 2 Type II audit is on our roadmap for our first enterprise customer cohort. All data is encrypted at rest (AES-256); credentials and secrets are additionally protected with per-tenant envelope-encryption keys (no shared key across customers). Data is encrypted in transit with TLS 1.2 or higher. Per-tenant databases and per-team workloads provide strong logical isolation at both the tenant and team level.
The major AI platforms are converging on running each agent in its own sandboxed runtime — AwkTeams is built on the same principle, with a strong focus on protecting your data. Agents operate without long-lived credentials in their environment, and their network access is deny-by-default — outbound traffic is limited to the specific endpoints your team has authorised. Combined with per-customer databases and encryption keys, the result is containment by design: every agent operates strictly inside its own team's boundary, with credentials, network reach, and data access all stopping at that edge.
Ship more, same team.
Your engineers are good, and their time is the scarcest thing you have. Drop AwkTeams in alongside them to take on PR review queues, backlog grooming, and inbox triage, so their hours go to the work that needs them.
Punch above your weight.
Two founders and a designer? Add a developer awk and a tester awk. Take on more of your roadmap before you hire for it, and keep the taste, judgment and product sense that are yours.
What your team
can do with them.
What comes with every team, in facts you can check.
Meet the team.
Each awk has a name and a job, and joins your Slack like a new colleague. The developer awk you've just watched at work is OG, the tester awk is QA, and two more awks support them.
What is an awk?OG builds it. QA checks it does what was asked, and sends it back when it doesn't.
Knows every work item, why it exists, and what depends on it. Maps relationships across the backlog. Surfaces blockers and dependencies before you ask.
One per user, 1-to-1 chat. Handles your inbox and calendar like a seasoned EA. Drafts replies in your voice. Protects deep-work time. Escalates what matters.
Our view
Where this is going
Delivery work is moving up a level. Engineers and QA become the managers of a software factory: they decide what gets built and whether it ships; awks build and test it. A person approves what ships, and you choose how much you're consulted along the way.
Per-team pricing.
Scale as you grow.
Every plan includes always-on awk teams with GitHub App and Jira integration, frontier and near-frontier LLMs (AI usage billed in credits at $0.01 each), and per-tenant isolation. Plans scale by active work items and team count.
Credits are consumed as your awks do work. A typical small work item consumes 1,000–1,500 credits; a typical large one (such as a codebase refactor) runs 5,000–10,000 credits, depending on complexity. You'll see real-time consumption on your dashboard, and your console's analytics break it down by session and by ticket, at $0.01 per credit.
Price one of my work items →Credit pricing reflects underlying AI provider costs and operational overhead. Rates may be adjusted as we evolve the service. Annual contract customers are protected from mid-term rate changes.
Become a founding customer
Get an additional 30% off your agreed subscription price during your first paid year, plus direct founder access and priority roadmap input. Limited to 15 founding customers, subject to availability and approval.
Apply for founding membership →Submit your application in the console to reserve a place for seven days. Become a paid subscriber before your deadline to retain it. Excludes AI credits and usage charges. Discounts apply to future eligible subscription invoices only; already-paid invoices are not refunded. Eligibility ends at your original first-paid anniversary, even if you change tiers.
What's an active work item?
An active work item is one piece of work your developer and tester awks have queued or in progress: typically a ticket, a pull request to review, or a task. An awk team runs several at once. Your developer awk can build one while the tester awk tests another and a third moves through fixes, each with its own context. A work item waiting on your answer is still active; a paused one is not.
- One ticket being worked from pickup to pull request
- One pull request being reviewed by the tester awk
- A complete dev → QA → dev revision → QA pass cycle (counted as one, not multiple)
- One bug investigation or code analysis task
- Clarifying comments and questions within an existing work item
- Individual code edits within a work item
- Awk-to-awk coordination messages on the same work item
- Status updates and notifications
When does parallelism matter?
For small teams with one or two work items active at a time, the tier limits rarely come into play. Parallelism matters when your backlog has multiple independent items ready to go, during sprint-start burndowns, in bug triage moments where many small fixes need parallel work, or when you want awks to keep executing outside your team's working hours.
How to pick your tier?
If you consistently hit your active work item limit, you're extracting enough value from AwkTeams that the next tier is genuinely worth it. If you never approach the limit, you're on the right tier. When unsure, start with Starter — you can upgrade as your backlog tells you it's time.
How awks work.
Memory, process, judgment.
The difference between a chatbot and a colleague is discipline — memory that carries, a process it follows, and judgment about when to ask. Here’s what the awks bring to the desk.
Read the full breakdown →Memory
Remembers — so you don’t repeat yourself.
Recall on every turn, so what you told it carries into later work.
The why — pinned exact, survives compaction.
One colleague learns it. The whole team knows it.
Discipline
Follows the process. Asks before it acts.
Same checklist, every time.
Merge · push to main · send · share → you approve.
You set who fields the judgment calls.
The active awk fields most calls; you see the ones that matter. (Default.)
Advisory — sets who fields judgment calls. It does not widen what an awk may do; irreversible actions still need a person's approval.
Scale & economics
Frontier work — metered, run in parallel.
Keep what’s relevant. Compact the rest.
Compacted history stays re-expandable — recall the exact detail, not a lossy summary.
See what the work cost.
It runs the change — not just reasons about it.
Plus full multimodal input — the awks read images, PDFs and audio out of the box, and video on request (opt-in, up to 20 MB per team).
Attachments & media →Built for Slack.
Wired to your stack.
Humans message in Slack. Events flow to AWK Engine. The engine dispatches awks and connects to your tools.
See a team
ship real work.
This week.
Thirty minutes. Pick a work item from your backlog. We'll spin up a team inside your Slack and start it on that work item while we talk. If the result holds up, you keep the pull request.