Engagement timeline / calendar day 1

Day 1 commit access in an AI engagement, hour by hour.

Every AI vendor pitch deck says "embedded engineers" somewhere on slide three. Almost none of them publish the literal day 1 sequence. This is ours: who triggers what at 09:15, what the first PR looks like, why it only changes one file, and what happens if the client cannot land write access before the day is over.

Matthew Diakonov, Written with AI

Published May 5, 20267 min read

Direct answer (verified 2026-05-05 against the engagement template)

Calendar day 1 of an fde10x engagement. SSO invite by 09:15 client time, GitHub org write access by 11:00, signed commit + SSH config by 13:00,PR #0(a 14 line CODEOWNERS edit) merged by 16:45.

If any step slips past EOD day 1, the engagement clock pauses and billing pauses with it. The clause is in the MSA template. The most common cause of a pause is a vendor-account approval queue on the client side, not the engineer's setup.

"Commit access" in this guide means: write on agents/**, eval/**, and infra/staging/**, plus the right to open and merge pull requests through the client's normal review process. It does not mean admin on the org, write to production infra, or write to the repo root.

The day 1 timeline

Hour by hour from kickoff to merge. Times shown in client time zone. Your IT team triggers the SSO step; everything else is on us. The whole sequence is roughly seven hours of clock and about two hours of actual engineer work.

day-1-onboarding.log

What PR #0 actually changes

The smallest possible change that proves the loop works. Four added path globs in .github/CODEOWNERS, a comment block explaining thepilot/branch prefix, and nothing else. No agent code. No infra. No eval cases. Those land in week 2 in the seven PR sequence, not today.

.github/CODEOWNERS

The PR #0 description we open against your main branch

One file changed. +14 / -0. Two named reviewers. The body is three short paragraphs that the client tech owner can read on their phone between meetings, because that is exactly when most day 1 PRs land for review.

PR0.md

Why "day 1" is the load bearing constraint, not a stunt

The reason day 1 commit access is non-negotiable is not that we want to look fast. It is that every other commitment downstream depends on the loop being live. The week 2 prototype rubric assumes the rubric.yaml file already lives in your repo and is reviewable by your team. The week 6 handoff assumes the named client engineers on CODEOWNERS have reviewed real PRs on the work, not just looked at a deck.

When access slides to week 2 or week 3 of an engagement, the most common failure mode is that the senior engineer ends up working in their own fork and the client team never reviews any of it. By the time the prototype lands, nobody on the client side has touched the code. That is how an engagement reaches week 6 with a slick demo and zero owners on the receiving end. Day 1 commit access is the smallest mechanical fix for that failure mode.

Stated differently: the artifact we leave behind in week 6 is not the agent. It is the eval harness, the runbook, and a CODEOWNERS file that names the people on your team who own the agent. PR #0 is the first row of that CODEOWNERS file. Every later PR is downstream of it.

Day 1 checklist (client side)

Most of these belong to client IT, not the engineering team. Bring your IT lead to the kickoff call so the SSO invite and the CODEOWNERS edit are not blocked behind tickets that take two days.

What needs to be true by EOD day 1

Client IT triggers the SSO invite by 09:15 client time
Engineer accepts SSO + GitHub org invite by 11:00
Engineer is on team @<client>/eng-agents with write on agents/**, eval/**, infra/staging/**
Signed commit (GPG or sigstore) and SSH key configured locally by 13:00
Branch protection allows the pilot/ prefix; no other prefix is granted
Engineer is on #eng-agents and #fde-engagement Slack channels by 11:30
Read-only standup attendance at 14:00 with the client team
PR #0 (CODEOWNERS update, one file, +14 / -0) opens against main by 15:30
PR #0 has two named human reviewers, not auto-merge
PR #0 merges and CODEOWNERS routes the four engagement path globs by 16:45
If any of the above slips past EOD day 1, the engagement clock pauses and billing pauses

Day 1 access vs the typical AI consultancy first week

Five rows from real scoping calls. The left column is the shape we ship; the right column is the shape we replaced.

Feature	Typical AI consultancy week 1	fde10x day 1
When the AI vendor's engineer first commits to your repo	Week 2 to week 6 of a Statement of Work. Many teams never grant write access at all and review code over screenshare. The first commit is the consultant's name on a README, weeks after the contract is signed.	Calendar day 1, 16:45 client time. PR #0 is a 14 line CODEOWNERS update. Reviewer pool is two named humans. The merge time is in the engagement runbook because the next six weeks depend on it.
What permissions the engineer holds on day 1	"Read-only access for security review." The vendor cannot push code, so they paste it into chat. The client copies it, runs it locally, finds a bug, and the loop is a day long instead of forty minutes.	Write on agents/, eval/, infra/staging/**. No write on production infra. No write on root. No admin on the org. The exact path globs are in CODEOWNERS for everyone to read.
What happens if write access does not land by EOD day 1	The clock keeps running. Hours are billed against "discovery" while the engineer waits for VPN credentials. The first invoice arrives before the first commit.	The engagement clock pauses and billing pauses. The MSA carries the clause. The pause restarts when the IT ticket clears. We have triggered this clause twice; both times the cause was a vendor-account approval queue at the client, not anything we did.
Who owns the work after the engagement ends	A Confluence page, a recorded handoff call, and a vendor-attached runtime that nobody on the client side has ever pushed code to.	The CODEOWNERS file from PR #0 already names the client engineers who own each path. By week 6, every file the engagement touched is co-owned with a client engineer who reviewed at least one PR on it. The leave behind is not a handoff event; it is the steady state.
What goes in the day 1 PR description	No PR. The first artifact is a project plan in a deck. The deck is updated; the repo is not.	Three paragraphs. Why this is the first PR (proving the loop works). What changes (path globs only). Why it matters more than it looks (the reviewer routing on every later PR). Net change line. Two named reviewers.

What you can copy off this page

The CODEOWNERS shape, the four path globs, thepilot/branch prefix, the "PR #0 only changes routing" rule, and the EOD day 1 SLA are not proprietary. Run the same shape on your next vendor engagement, internal AI hire, or contract embedded engineer; the pattern works whether you ever talk to us or not.

What is hard to copy is the discipline of refusing to write any agent code on day 1. The temptation is to push something the client can demo on the kickoff call. The cost is that the loop never gets tested, the routing is wrong on every later PR, and the leave behind in week 6 has nobody on the receiving end. PR #0 looking unimpressive on day 1 is the point.

Want a named senior engineer with day 1 commit access on your repo next Monday?

Sixty minute scoping call. You leave with a written one-pager that names the engineer, the four CODEOWNERS path globs, the day 1 SLA, and the cancel-and-refund clauses for week 2 and week 6. The engagement template is on the call screen so you can copy what works whether you sign or not.

Frequently asked questions

What does "day 1 commit access" literally mean?

By end of business on calendar day 1 of the engagement, a named senior engineer at fde10x has SSO + GitHub org membership, write permissions on agents/**, eval/**, and infra/staging/**, and has merged PR #0 (a 14 line CODEOWNERS routing change) into the client's main branch. "Commit access" specifically means write to a defined set of path globs and the right to open and merge a pull request through the same review process the client engineers use.

Why does PR #0 only touch CODEOWNERS instead of starting on the agent code?

Because the loop being tested on day 1 is the loop, not the code. PR #0 verifies five things at once: (1) SSO works; (2) write access on a real path was granted; (3) signed commits are accepted; (4) two named human reviewers see the PR; (5) the merge happens through CI, not by the senior engineer's own admin. Any of those failing on day 1 is cheaper to find with a 14 line PR than with the 450 line PR #1 in week 2.

What if the client cannot grant repo write access by end of day 1?

The engagement clock pauses and billing pauses. The clause is in the MSA template. The most common cause is a vendor-account approval queue at the client (legal review, security review, IT ticket queue). The pause restarts the morning the ticket clears. We have triggered this twice; both engagements still finished inside the original calendar window because the week 1 work compresses cleanly when the day 1 access lands by day 3 or 4.

Why should I let an outside engineer commit to my repo at all?

The alternative is a vendor who paste-bombs code into Slack or a screenshare. That review loop is a day per change versus forty minutes. It also concentrates the artifact in the vendor's machine instead of your repo, so when the engagement ends you have no code to inherit. The path-glob scope (agents/**, eval/**, infra/staging/**) is narrow enough that the engineer cannot touch payment, auth, or production infra. CODEOWNERS, branch protection, and required reviewers are all you need; you already use them on your own engineers.

Does fde10x bring its own platform or licensed runtime that gets installed in our infra?

No. We are model vendor neutral and platform agnostic. Whatever model provider you have already chosen (Anthropic, OpenAI, Bedrock, Vertex, Azure OpenAI, or open weight), the prototype runs on. We do not deploy a vendor-attached runtime. Everything we ship lives in your repo, in your CI, on your infra. The eval harness, the rubric, the runbook, and the agents/** code are yours when the engagement ends. There is no per-seat license to keep paying.

How does day 1 relate to the week 2 prototype and the week 6 handoff?

Day 1 is the access loop. Week 2 ships a prototype in your staging on a written rubric (the cancel-and-refund clause sits on that). Week 6 hands over the runbook and a 90 minute transfer session. Day 1 is the smallest moving part. If the day 1 sequence does not land cleanly, the week 2 prototype timeline gets discussed before any agent code is written.

What does the rest of week one look like after day 1 commit access lands?

Day 2 reads the existing eval/** code (whatever is there, often nothing) and writes a one-page rubric draft. Day 3 opens PR #1, the rubric.yaml file, against main with the same two named reviewers. Day 4 ships the first eval cases (cases.yaml, ten cases pulled from production traces if you have them, hand-written if you do not). Day 5 wires the eval into your CI as a non-blocking job and lands the first agents/** scaffold so the prototype directory exists before the week 2 work starts. By Friday EOD week one, the loop has been used five times: PR #0 on Monday, PR #1 to PR #4 across Tuesday through Friday. None of those PRs are large; the largest is around 120 lines.

Who is the first reviewer on PR #0?

Two named humans, both on your side. The client's tech owner (usually the VP or director who signed the engagement) and the engagement owner (a fde10x partner who is named in the contract, separate from the engineer doing the work). The senior engineer doing the work does not self-review or self-merge. That separation is what keeps the loop honest from day 1; the same pattern carries through every PR for the next six weeks.

How do I verify any of this before signing?

The free scoping call ends with a written one-pager that names the senior engineer, the four path globs, the day 1 SLA, and the cancel-and-refund clauses for week 2 and week 6. The engagement template (CODEOWNERS shape, branch protection rules, PR #0 body) is on the call screen. None of it is contingent on signing; if you take the one-pager and run the engagement yourself, that is a fine outcome too. The page you are reading now is most of what is in the runbook.

Other engagement-shape pages on fde10x.com