The AI Architect's First 90 Days
An AI architect’s first 90 days should move from diagnosis to one working system, not from diagnosis to a roadmap document. Days 1–30 map the business and produce a written findings memo. Days 31–60 turn the single highest-value finding into one production workflow with a named owner. Days 61–90 prove it with metrics, wire in governance, and set the cadence for what comes next.
What should an AI architect do in the first 30 days?
The first 30 days belong entirely to diagnosis, not delivery, because committing to a build before the business is mapped guarantees the architect solves the wrong problem well. This is the same discipline that governs week one: inventory every system, data source and workflow that AI could plausibly touch, and hold structured conversations with the people who actually run each one, not just the executives who sponsor the hire. By day 30, the deliverable is not a slide deck of possibilities but a ranked written diagnosis: which workflows are AI-ready, which are blocked by data or process problems no model can fix, and which look attractive but carry disproportionate risk. Generic onboarding advice built on Michael Watkins’s original 30-60-90 framework tells new leaders to spend this window “learning” in the abstract; an AI architect’s version of learning has a concrete artefact at the end of it, because vague learning that never resolves into a written position is indistinguishable from stalling.
What changes in days 31 to 60?
Days 31 to 60 shift from mapping to building exactly one thing, chosen from the diagnosis rather than from whoever lobbied hardest for a tool. The mistake most 90-day AI plans make, including several aimed at architects, is treating this phase as parallel workstreams across five layers of the stack at once. In practice, an architect operating alone or with a small team gets further by picking the single highest-leverage workflow the diagnosis surfaced and building it end to end: data access, model or agent logic, human checkpoints, and a rollback path. This is also the phase where vendor evaluation happens for real, not in the abstract, because a live pilot exposes whether a platform’s claims about integration, latency or data handling hold up under the business’s actual conditions rather than a sales demo’s curated ones. Architects who skip straight to comparing vendors in week one end up locked into a platform before they know which problem it needs to solve; doing it here, against a diagnosed need, is the difference between buying a tool and buying the right tool.
What should be true by day 90?
By day 90, one AI workflow should be running in production, with a named human operator, a documented escalation path, and a measured baseline showing it beats the process it replaced. That bar, drawn from implementation frameworks used outside the architect discipline specifically, is deliberately narrow: not five pilots, not a completed enterprise roadmap, one thing that works and that someone is accountable for when it doesn’t. The narrowness is the point. A roadmap with no working system behind it is a set of promises; a single production workflow with clean metrics is proof the architect’s diagnosis was correct, and it is the evidence that earns the mandate to build the next one. This is also the point at which governance stops being a slide about principles and becomes a mechanism: who can change the model, who reviews outputs, what triggers a human review, and how a failure gets logged and fed back into the next diagnosis cycle.
Why does the 90-day arc matter more for AI architects than for other technical hires?
The 90-day arc matters more for AI architects because the role’s entire justification rests on sequencing: diagnose, then build, in that order, and 90 days is roughly the shortest window in which both halves can be demonstrated credibly. A backend engineer or data analyst can show value inside week one by shipping against an existing backlog; an AI architect who does that has skipped the diagnosis that makes the role worth hiring for in the first place. But diagnosis alone, stretched indefinitely, looks indistinguishable from indecision to a board that is watching competitors announce AI initiatives. Ninety days is enough time to do the diagnosis properly and still deliver something real off the back of it, which is exactly why it has become the standard window against which the role gets judged, fairly or not.
What derails most 90-day AI plans?
Most 90-day AI plans derail because they front-load tool selection instead of front-loading diagnosis, so the pilot in month two ends up justifying a purchase decision instead of testing a hypothesis about the business. A second common failure is the reverse: architects who treat the entire 90 days as discovery, produce an excellent findings memo, and have nothing running by day 90 to show for it, which reads to sponsors as analysis without output. A third failure, less discussed, is skipping the governance and observability work in the rush to hit a day-90 production deadline, shipping a workflow with no owner and no escalation path, which fails quietly a few weeks later and erodes trust in the next thing the architect proposes. The fix in all three cases is the same discipline: sequence diagnosis before build, but hold both to a fixed, visible deadline rather than letting either expand to fill the available time.
What does a 30-60-90 day plan look like for an AI architect?
A 30-60-90 day plan for an AI architect sequences one month of diagnosis, one month building a single workflow, and one month proving it with metrics and governance.
| Phase | Primary activity | Key output by end of phase | Risk if skipped |
|---|---|---|---|
| Days 1–30 | Diagnose: system inventory, stakeholder interviews, data readiness check | Written, ranked findings memo | Building the wrong thing well |
| Days 31–60 | Build one workflow end to end, from the top-ranked finding | Working pilot with rollback path, vendor choices tested under real conditions | Locking into tools before the problem is understood |
| Days 61–90 | Prove and govern: measure against baseline, assign owner, wire escalation | One production workflow, named operator, documented escalation path | A live system nobody is accountable for |
FAQ
Does the 90-day plan replace the week-one diagnosis? No. The week-one diagnosis is the start of days 1–30, not a separate step; the first month simply extends and finalises what begins on day one.
Should an AI architect commit to a vendor or model stack before day 90? Only provisionally. Real vendor evaluation happens inside the days 31–60 pilot, where claims about integration and data handling get tested against the business’s actual conditions rather than a sales demo.
What if the business wants five AI initiatives running by day 90, not one? Push back on scope, not on ambition. A single production workflow with a named owner and clean metrics is stronger evidence of capability than five pilots with no accountability behind any of them.
Who should own the workflow once it’s live? A named person inside the business unit it serves, not the architect. The architect’s job is to diagnose, build and hand over with governance attached, not to become the permanent operator of every system they stand up.
What happens after day 90? The cadence repeats: the production workflow’s real-world performance and failures feed back into a fresh, narrower diagnosis for the next highest-value workflow, rather than starting from a blank slate.
Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.