An agent at Cloudworkz is a bounded process: it takes a defined input artefact, loops with an LLM and tools until a defined done-criterion is met, and hands a defined output artefact to the next step, all under explicit guardrails, with deliberate human checkpoints where judgement matters.

Three things follow. An agent is a loop, not a single inference. Every agent has a defined shape: input artefact in, output artefact out, with explicit scope. And humans are not an afterthought; checkpoints sit deliberately at the steps where judgement matters more than throughput.

Every agent declares the same eleven components. They are how we describe an agent, debug it, and judge whether it is world-class or mediocre.

The agent team replaces the cycle Werner runs by hand today: a problem surfaces, gets sharpened into a spec, an ADR is drafted if architectural, a brief is written, a build happens, tests run, the PR is reviewed and merged, the tracker is updated. The manual workflow is the spec for the agents. Fourteen agents sit in the linear flow (four conditional), with three cross-cutting agents and three supporting services. Human checkpoints (★) are blocking sign-offs.

At the technical level an agent is a program that loops with an LLM:

state = { messages: [systemPrompt, taskBrief] }
while not done(state):
    response = LLM.call(state.messages, tools=allowlist)
    if response.is_tool_call:
        result = execute_tool(response.tool, response.args)
        state.messages.append(response, result)
    else:
        state.final = response; break
    if cost > budget or steps > limit: escalate(); break
return state.final

The runtime is whatever program hosts this loop and provides the LLM connection and the tools. Three runtimes, increasing in production-readiness:

The commitment is R3 for production. The pipeline-engine knows the pipeline shape and invokes the right agent at the right time; the agent-shell provides everything universal (loop, model call, tool execution, cost tracking, transcripts, escalation routing). Each agent is a thin config + prompts + tool list on top. Sequencing: prototype in Cowork or Claude Code, prove the prompt/tools/contracts, then migrate the config to a monorepo service. Cheapest to start with: a-spec-writer and a-tracker-curator.

The architecture is enforced by what is in the agent's context plus how its system prompt constrains it. Four mechanisms keep agents aligned: curated context (a-context-curator injects the relevant ADRs and architecture), constrained system prompts ("align with signed ADRs; if you see a conflict, flag it, do not override"), the conflict detector as a handoff safety net, and human sign-off on high-stakes work (Werner approves every ADR; no machine-generated architecture lands unreviewed).

Every Box and Acid folder follows the same three-layer discipline. This is the propose-then-apply bridge between human authoring and canonical content.

Four boxes per tenant. Each answers a different question. Acid reads Box via wikilink — Brand-Box never copies into Acid. The moment a Brain-Box document acquires a committed number, a new Biz-Box document is created — the Brain-Box origin stays.

Five Acid folders per tenant. Each is the production counterpart to the Box strategy it executes. Acid reads Box via wikilink. Acid produces outputs and routes them to their destination — Acid never retains finished outputs.

Every file in the vault is a Doc. The type determines where it lives, what frontmatter it carries, and what consumes it. Every canonical (locked) doc carries universal frontmatter.

Surface map

How data flows between surfaces

Which surface for which job

The seven verbs

Keep to these seven. If a request does not fit one, that is a signal the intent is new and should be discussed before a verb is added.

Role-specific verbs, used sparingly only where the seven do not carry the meaning: coach and grade (Marie, live and post-call), ingest (Roy / Tom, the transcript fan-out, already an alias).

The slot set

Slots are the variables. Same name everywhere, so "campaign" never appears as "promo" in someone else's command.

The command pattern

Worked parses

Registered commands (work today)

The stable, works-now set from the alias registry. PARTIAL and NO commands are not registered here, they sit in the gap list until built.

Capability gaps snapshot

Across 42 commands mapped over 7 seats. The honest state of what works versus what is still being built.

Full per-person lexicon and ranked build list live in the vault: Projects/Cloudworkz-OS/reports/2026-06-04-team-command-lexicon-V1 and ...command-capability-gaps-V1.

Folder Structure

Transcript Sources

Storage Model + Wider System Feed

Cluster 1 — OS operations (9)

Day-to-day OS maintenance, session management, and vault governance.

Cluster 2 — Code and quality (7)

Code review, debugging, structured grilling, and thinking quality.

Cluster 3 — Build and render (10)

Document creation, HTML renders, and artefact production.

Cluster 4 — Stakeholder and investor (2)

Cluster 5 — Transcript and intelligence (3)

Cluster 6 — AI-native discovery (11)

The ten-component AI-native discovery framework plus orchestrator.

Cluster 7 — Acid-Content compliance spine (10)

End-to-end regulated content production from claim verification to channel-ready copy.

Cluster 8 — Sales operations (3)

Cluster 9 — Unlock regulated domain reviewers (7)

Unlock-specific compliance and regulated-advice reviewers.

Cluster 10 — Learning and education (3)

Cluster 11 — Incubator and ideation (4)

From UCB audit — frameworks applied to produce Content Matrix + ACU Register

Parent/Library/_frameworks/ — on-disk scan additions (2026-06-10 rebuild)

Framework files present in Companies/Parent/Library/_frameworks/ but absent from the 2026-06-07 render. Regenerated from directory scan.

Pre-existing vault frameworks — confirmed before UCB audit

Templates from UCB FST Audit — built and ready to file

Pre-existing vault templates

Backlog — all open items

Open questions — for Werner

• Q1 — Products axis. Does the five-axis structure rewrite ratify Products/ as a top-level peer of Companies? Scaffolded provisionally 2026-06-01; lean = yes, because products are sold and consumed across every brand.
• Q2 — Tenant-specific product strategy. When a product's strategy / working docs are tenant-specific, do they live in Products/{product}/ with their own working/locked discipline, or stay in the consuming tenant's Box with the Products/ record pointing to them?
• Q3 — Naming disambiguation. Resolve the three-way collision: the Acid-Data vault folder vs the "ACID Data" product vs the Axiom product (all touch ingestion / data). Confirm Axiom's commercial name and tiering (currently TBD).
• Q4 — Dev. Confirmed a product, not a company: record lives in Products/Dev/, the build lives in GitHub, pre-commercial instances (mini-Cloudz etc.) are Code. Werner presentation owed.

Employees

Contractors

Per-tab source map

The vault is not a documentation site. It is the operating system. Cloudworkz OS mirrors the intended product: vault folders map to product Boxes (Brain-Box, Biz-Box, Brand-Box, etc). When Tom and Claude work here, they are simultaneously operating the business AND building the product. Every structural decision in the vault is a design decision for what Unlock will be.

One rule: everything has a home. Nothing in root. If unsure, check Tom or use the Submit tab to ask.

Claude operates this vault as the org AI assistant in Cowork mode. Every session starts by identifying who you are (profile selection). Your active profile determines where your outputs land: daily notes, tasks, drafts all route to your Team profile folder.