# How AI Pods Work > Story points, two-week cycles, and continuous deployment inside them. How a Koombea AI Pod turns your priorities into production software. Source: https://www.koombea.com/ai-pods/how-it-works/ --- A Pod runs one loop, repeatedly. Your priorities become specs, specs drive AI-First implementation, and automated gates decide what reaches production. ## The pipeline, end to end Traditional teams lose most of their time to handoffs. A product manager writes a ticket, an engineer interprets it, QA guesses at the intent, and the gap between those three readings becomes rework. A Pod removes the interpretation gap by making the spec the contract. Each item states its inputs, outputs, and edge cases before implementation starts. The scenarios that verify it are written from that same spec before the build, by someone other than whoever builds it. ### One item, four stages - Priority: You say what matters most this cycle - Spec: Inputs, outputs, edge cases, estimated in points - Build: AI-First implementation, reviewed before merge - Gate: Tests written from the spec, plus automated review, decide the merge ## From intent to production, in one tight loop Intake and Scoping: You share the goal. We break it into estimated, prioritized backlog items. (1 to 2 days) Spec and Design: Each feature gets a precise contract of inputs, outputs, and edge cases, plus clickable prototypes to validate direction before a line of code. (Hours, not days) AI-First Build: Implementation runs AI-First. We review and refine every output before it merges. (Continuous) Integrated QA: Scenarios come from the spec and are written before the build. The pipeline enforces them. Quality is a gate, not a phase. (Built in) Continuous Deployment: Automated pipelines ship reviewed work to production safely. (Continuous) Monitor and Maintain: AI-First monitoring feeds issues straight back into the backlog. (Always on) ## The loop, and the way back out of it ## Two-week cycles, continuous deployment inside them The cycle is a planning rhythm, not a release gate. Work reaches production as soon as it clears its quality gate, which is often several times a week. The two-week boundary is when we re-cut priorities with you and publish the capacity report. That separation matters. Releasing on a fixed fortnightly date forces finished work to sit and wait, and waiting work rots. Shipping continuously while planning on a rhythm gives you both a predictable conversation and a short path to production. ## We run the cadence. You do not staff it. A committed scope needs a real rhythm behind it. Every two-week cycle has planning at the start, a short daily stand-up, and a review at the end where delivered work is demonstrated and accepted. We run a retrospective after that. All of it happens whether you attend or not. What changes is how much of it lands on your calendar. You are in the Priority Sync and the end-of-cycle review, because those are the two moments where your decision actually changes the outcome. The rest reaches you asynchronously through your Delivery Manager and the weekly capacity report. Your team spends its time reviewing working software, not sitting in status meetings. ## Why that report is never late The report is generated from the delivery record rather than assembled for the meeting. The platform a Pod runs on carries each approved item from its spec contract through generated tests and automated merge gates, and records what shipped against the item it came from. Counting throughput is a read of that record. This is the part that makes a fixed commitment possible at all. You cannot promise throughput you cannot measure, and you cannot measure it by asking people how their week went. Nobody assembles the report, which is why it is never late and never flattering. ## How we verify before we build The order of these three documents is the whole method, and getting it backwards is why delivery with agents so often produces fast rework. First the spec: what gets built, for whom, and what done looks like, with the edge cases and the exclusions written down rather than left to inference. Then the validation plan, which commits to how each criterion will be proven. That plan is written before any implementation, because a test written after the code only asks whether the code does what it does. Only then the implementation plan, which is built from both, so whoever executes knows what they will be measured against before they start. One spec, three readers. Engineering builds from it, quality writes the scenarios from it, and design works the states and flows from it. When all three start from the same contract, the most common defect class disappears: three people building slightly different mental models of the same feature. It also means work does not start until all three inputs exist. If one is missing, that is the thing to say out loud, not the thing to work around. - Spec first, with edge cases and exclusions explicit, not inferred - Validation plan before implementation, never after - Implementation plan built from both, so nothing is discovered at build time - Engineering, quality and design all working from one contract - How complete the spec needs to be scales with the risk: anything touching auth, permissions or payments gets the full treatment ## What done means "Done" is the word most likely to mean two different things to the two people using it, so we define it twice. A single item is done when it is built, deployed to staging, and accepted by you in the end-of-cycle review. That is the bar that keeps a cycle moving, and it is deliberately a low ceremony one. A phase is a different matter, because phase acceptance is what starts the warranty. Every acceptance criterion has a passing test, every edge case we listed has a verification, coverage thresholds are met on the code we wrote, and no P1 or P2 defect is open. The production launch checklist is complete, we hand over the architecture overview and deployment runbook, and source and pipeline access is transferred to whoever you name. Then you sign off in writing, and the warranty clock starts. If any of those is not demonstrably true, the phase is not delivered, and we do not get to call it delivered because the calendar says so. - Every acceptance criterion has a passing test, every listed edge case a verification - No open P1 or P2 defects at handoff - Production checklist done, runbook and architecture overview handed over - Source code and pipeline access transferred to your named owner - Written sign-off from you, which is what starts the 30 day warranty ## What we need from you A Pod is fast because the inputs are small and structured. We need about an hour a week from one decision-maker who can approve deliverables and answer questions, and feedback on review items inside about three business days. That is the floor rather than the ceiling. You do not need to staff a project manager against us, sit in ceremonies, or maintain a backlog on our behalf, because your Delivery Manager does that and reports on it. Plenty of clients want to be in the detail every day, and that works too. The hour is what delivery requires, not a limit on your access. - About an hour a week from one named decision-maker with authority to approve - Feedback on review items within about three business days - Access to the systems the work has to integrate with