Monday: the plan is a list of tickets
The week starts at your standup, not ours. The pod lead and the forward-deployed engineer join the same call your team already runs, at the same time, with the same people. There is no separate vendor meeting.
The week's tickets are written, sized, and in order. Your backlog owner signs off on the order. Nothing starts on a verbal ask, and a ticket is not done until it is closed in production. That rule sounds small. It is the whole system. The backlog is the contract, and your team can open it at any time and see what is being built and why.
Here is what a Monday ticket looks like inside a pod at a freight broker, with example data: "Quote request parser: email to a structured lane. Done when a quote email becomes a record with origin, destination, equipment, and date, and anything under the margin floor waits for a person." That last clause is the approval gate, and it is written before the code is.
Tuesday to Thursday: one loop, run many times
Most of the week is the same loop: ticket, pull request, CI (the automated checks that run on every change), review, merge, deploy. Tests and CI go in before the first fix lands, because a fix without a test is a guess with a commit message.
CI proves every change. A named approver clicks merge on any change that touches money or access, and every step is logged with who did it and when. The engineer's job is less typing than you would expect and more judgment: what the ticket actually means, which system of record wins when two disagree, what the rollback is if the deploy goes wrong.
What the engineer touches
Your systems, in production. Access only through your SSO and IAM, scoped per person and agent. The engineer builds the connector to your CRM or your accounting system, writes the runbook for it, and ships it to the environment your team uses, not a staging site that never becomes real.
What the engineer does not do
Disappear for six weeks and come back with a build. Ship to a demo environment and call it live. Write a deck. If a ticket is blocked, it is blocked in writing, with a name next to it, so your backlog owner can clear it or reorder.
Weekly demos, then a monthly usage and savings review
If the quote parser shipped, you see it in the next demo, on your systems with your data, not on a slide: a quote email goes through it in front of your operations lead, with the record it produced and the one it held for approval.
Day 90 or 120: the first system is measured
At day 90 for a small pod or day 120 for a large pod, the first system is measured against the number from the assessment. Not against hours. Not against tickets closed. Against that number, on a metric your finance team already tracks, on your systems.
You see the result, not a status deck. Then you decide what the pod builds next.
From February 2027, Roo runs inside every Run client. Roo is the cockpit a company runs its AI crew from. The crew works inside the company's own systems, under its rules. The Brain belongs to the company. The memory, the approval rules, and the audit log the pod built stay with your team after the engineers roll off. So do the runbooks.
A weekly loop costs less than a monthly surprise
An engineer you brief once a month ships you a surprise. An engineer in your standup ships you the thing you asked for, and you find out within the week if it is wrong. The second one is cheaper to correct, and it is the only way we have found to put AI into a real business without the business stopping.
More on the pod
The FDE Pod page covers who a pod is for, small versus large, and the 12-month term. The How we work page has the full rhythm of a week in a pod. Day 90: what a production checkpoint means goes deeper on the measurement. The playbook on running AI in production covers what we watch after the checkpoint.
Book 15 minutes with Connor