Capabilities Agentic Engineering Open source Built for Claude Code
AWOS. The operating system for agentic engineering.
Coding agents know every framework and nothing about your product, and their assumptions surface at the pull request. AWOS, an open-source framework for Claude Code, puts the product first, so agents build from specs instead of guesses.
The evidence
Why agents need the product written down.
-
Fact 01 · Adoption
84%
AI tools are becoming standard.
84% of respondents use or plan to use AI tools, up from 76% a year earlier. Among professional developers surveyed, 51% already use them daily. AI tools are becoming a normal part of the working day.
Stack Overflow · 2025 Developer Survey -
Fact 02 · Delivery
80%+
Faster coding doesn’t guarantee reliable delivery.
More than 80% of respondents say AI makes them more productive. But DORA also links higher AI adoption to less stable releases. Individual gains need testing, feedback, and clear team practices to translate into reliable delivery.
DORA · 2025 report findings -
Fact 03 · Context
16% vs 54%
Fewer developers report missing context.
When developers select context manually, 54% say their AI assistant still misses relevant information. Among those whose tools store and reuse context across sessions, that figure is 16%.
Qodo · State of AI Code Quality, 2025
Everyone has the same tools now. What separates teams is whether the product is written down where the agents can read it.
The anatomy
Everything the agent needs to know.
Anthropic gives you the models and Claude Code. They can’t know your product, how your team works, or what done means here. AWOS is where that gets written down, and how the agent gets from a spec to a checked result.
The product, written down
The product, the roadmap, and the architecture, in plain language. Compiled from interviews and calls, team channels, Jira, documents, and the code. Every feature starts inside this frame, not from assumptions.
“This is a billing platform for SaaS finance teams. This quarter is usage-based pricing. We’re a modular monolith on Postgres; new services need a reason.”
How this team does things
Your conventions and review standards, installed as skills and specialist agents, so output follows your practices.
“API errors follow RFC 7807. Migrations are always backwards-compatible. Schema changes go through the database agent.”
What the work has taught
Tickets, logs, incidents, and the fixes and decisions behind them, wired in via MCP. Agents look things up instead of guessing, so a problem solved once stays solved.
“INC-88: the nightly invoice job timed out past 10k rows; it now runs in batches of 500. Don’t raise the batch size without a load test.”
L4 · Feature specs · the current unit of work
Functional
What the feature must do, as testable acceptance criteria and a definition of done.
“Done means: a team over its seat limit can’t add members, and the admin sees why.”
Technical
How to build it in this codebase: the approach, the touched modules, the constraints.
“Extend the quota middleware in billing-svc. Don’t touch the legacy enforcement path.”
What must never break
E2E and regression tests encode every hard-won lesson, so no change by human or agent can quietly undo one.
“Regression #212: proration always rounds toward the customer. E2E: an invoice is never sent twice.”
The path
How the layers get filled.
AWOS records your product, architecture, and team conventions. Each feature then moves from an agreed specification through implementation and verification, updating that shared knowledge as it ships.
Foundation · set up once · revisited as the product changes
- 01
Write the product down
→ L1 · Product knowledge baseThe product knowledge base in plain language: what it is, for whom, and the roadmap. Fable or Opus interviews the user. Read-only research agents go through the code and the documents to check the draft. What cannot be confirmed is left as an open question.
- 02
Record the architecture
→ L1 · ArchitectureStack, data, infrastructure, external services, observability: each area with its reasons and the alternatives considered, plus what is still missing. Research agents read the code so the record describes what is actually running.
- 03
Connect the team and the sources
→ L2 · L3The orchestrator compares the recorded architecture with the available collection to find the skills, subagents, MCP connections, and hooks this codebase needs. It selects the matching pieces for the project.
Feature cycle · once per feature
- 04
Create the specification
→ L4 · FunctionalFable or Opus interviews the user on the big picture, then runs research agents in parallel. One reads the code, one looks at how comparable products do it, one searches the internal docs when connected. Their findings become testable acceptance criteria, and every assumption is marked for the user. A verifier that has seen nothing else reads the spec cold and flags what a tester could not run.
- 05
Agree how to build it
→ L4 · TechnicalThe approach in this codebase, with each assumption put to the user before anything proceeds. Research agents check it against the code; the user's corrections are written down and stay.
- 06
Build and check
checks L4 · runs L5The work is sliced into runnable increments. The orchestrator hands each one to a specialist agent in its own context window and writes no code itself. Every acceptance criterion is checked against the result before the feature is marked done, and the record is updated.
Powered by Claude
Spec-driven development, optimized for Claude.
Provectus built its engineering experience into AWOS, an open-source workflow for Claude Code. Shared product knowledge, agreed specifications, and the team’s conventions guide Claude’s models and agents from intent to verified code.
Claude Partner Network · Preferred Services Partner
Provectus in the Claude Partner NetworkThe business case
Less rework, and a record that outlives the team.
We agree each measure with you before the first feature ships through the method, then compare it with your current baseline.
- 01
Fewer features built twice.
The misunderstanding is caught at the spec, where fixing it takes a conversation. In code, it takes a sprint.
Measured by Rework and change failure rate on features shipped through the method, against your baseline.
- 02
Intent reviewed like code.
Specs and the instructions your agents follow are diffs with an author, approved in a pull request and visible to the whole team.
Measured by Review rounds per feature before merge, against your baseline.
- 03
Onboarding without archaeology.
A new engineer, or a fresh agent session on any machine, reads the same files and starts with the full picture.
Measured by Time to first merged feature for a new engineer or a new agent setup.
- 04
Documents current as a side effect.
The commands read and write the product record as part of shipping. Nobody is asked to keep it up to date.
Measured by Places where the record and the code disagree, found by the check step, and how long they stay open.
Under the hood
Built with the discipline it enforces.
The details an engineering leader checks before trusting a framework, each with a receipt from the repo.
01 · Context-window economy
Specialist agents spend their own window
The orchestrator reads the spec once and hands each task to a specialist agent with the context it needs. Each specialist spends its own window, so the orchestrator's stays clear for the whole feature.
02 · Claude Code only
One host to test against
Every prompt is written against how Claude Code actually behaves, then revisited on each platform change: model shifts, tool renames, new built-in agents. One host means one set of behaviors to verify.
03 · Tested prompts
The prompts have a CI suite
A static linter checks the prompts' contracts on every pull request, fixture projects run real installs, and a separate QA suite replays real Claude Code sessions.
04 · Safe updates
Updates never eat your customizations
Your wrapper layer is preserved on every update by policy; a silent overwrite is treated as a bug. Migrations must prove they are idempotent before they ship.
05 · Zero dependencies
One package, no dependencies
The installer has no runtime dependencies at all: standard built-ins, on Node or Bun. Due diligence takes one look at the manifest.
06 · Nothing hidden
All plain text, MIT
Every prompt, template, and script is a plain-text file in the repo, under the MIT license.
One command installs it. Rolling it out across an organization is the work of Provectus’s Agentic SDLC program.
The questions
The questions we get first.
-
Do we have to change our git flow?
Keep yours.
AWOS can be configured around your existing branching, review, and deployment workflow, including the steps that require your team's approval.
-
Does it replace our tickets?
Keep yours.
Jira stays Jira. Wire it in as a source if you want agents reading tickets; your flow does not move.
-
What about security and compliance?
Keep yours.
AWOS adds Markdown, scripts, and command wrappers to your repository, plus a registry connection for hiring skills and agents. AWOS itself does not require a separate, continuously running service in your environment. You configure access to connected systems and decide how AWOS files go through your existing review process.
-
Does every change need a spec?
Keep your judgment.
Reaching agreement first takes time, so the method is for changes where being wrong costs more. Hotfixes, small edits, and prototypes go through the agent's own planning.
And the fifth, “our setup is unusual”, has an answer built in. Any command can take your own instructions. Open its wrapper in .claude/, add a line like “always run the integration suite after each task”, and the line is versioned with the repo and survives updates.