What an AI Architect Does in Week One
In week one, an AI architect does not select a model, write a line of production code, or promise a roadmap. They build an inventory of every system, data source and workflow that AI could touch, map who actually owns each one, and produce a written diagnosis of where the business is exposed and where it is ready. Everything built after week one rests on that diagnosis.
Why does week one matter more for an AI architect than other technical hires?
Week one matters more because the architect’s job is to prevent the company from building the wrong thing, and that only works if the diagnosis happens before any commitment to a tool, model or vendor is made.
Most technical hires can start contributing to existing work on day one: a backend engineer picks up a ticket, a data analyst runs a query against a known schema. An AI architect who does this instead skips the step that justifies the role. If they arrive and immediately start prototyping an agent or comparing vector databases, they have implicitly accepted someone else’s framing of the problem, usually the framing of whoever pushed hardest for a tool in the hiring conversation. That framing is frequently wrong, because the person proposing it does not have visibility across the whole business. Diagnosing first is not caution for its own sake; it is the only way to avoid spending months building a system that solves a problem the business does not actually have.
What does an AI architect actually do on day one?
On day one, an AI architect requests access to systems rather than opinions, and starts building a map of what already exists rather than what people want built.
The concrete list looks like this:
- Systems access: CRM, data warehouse, internal tools, ticketing systems, existing AI or automation deployments (including the informal ones: the ChatGPT subscriptions, the Zapier flows, the spreadsheet macros nobody documented)
- Org chart with function, not title: who actually owns customer data, who owns the sales pipeline, who owns compliance sign-off
- A first pass at existing AI usage: shadow IT is common; teams often already use AI tools without IT or leadership knowing, and this needs to be found, not assumed away
- Calendar for stakeholder interviews: booked for week one and two, not deferred to “when there’s time”
None of this touches a model provider, a framework, or an infrastructure decision. That comes later, and only once the diagnosis is complete.
Who does an AI architect need to talk to in the first week?
An AI architect needs to talk to the people who own outcomes, not just the people who requested the hire, because the person who pushed for an “AI architect” is often solving for a symptom rather than the underlying constraint.
That typically means:
- The sponsor (usually a founder, COO or CTO): what triggered this hire, what does success look like in six months, what has already been tried and failed
- Function heads (sales, ops, support, finance): where their teams lose time, where errors compound, what they’ve already tried to automate and abandoned
- Frontline staff: the people doing the repetitive, error-prone work the sponsor thinks AI should fix. Their account of the workflow is almost always more accurate than the manager’s
- IT or engineering leadership: what’s technically feasible given current infrastructure, security posture and data quality, and what constraints (compliance, legacy systems, contractual data restrictions) already exist
The gap between what a sponsor thinks the problem is and what frontline staff experience day to day is usually the most useful finding of week one. It is also the finding most new hires skip, because interviewing frontline staff takes longer and produces messier answers than interviewing the sponsor alone.
What should an AI architect avoid doing in week one?
An AI architect should avoid picking a model, committing to a framework, or promising a delivery date, because every one of those decisions depends on findings that do not exist yet.
The most common week-one failure mode is premature specificity: naming a vendor, a model family or an agent framework in the first week signals confidence, but it is confidence built on nothing. A second failure mode is accepting the sponsor’s framing wholesale, for example being told “we need a customer service chatbot” and starting to scope one, rather than asking what the actual cost of the current customer service process is and whether a chatbot is the highest-leverage fix for it. A third is treating governance and data privacy as later-stage concerns; if company data is going to touch a third-party model at any point, the compliance and security review needs to start in week one, not after a prototype already exists.
What does the end of week one actually produce?
The end of week one should produce a written diagnosis: a short document naming the two or three highest-value opportunities, the systems and data involved, the risks, and what still needs validating before any build decision is made.
This is not a full architecture document and it is not a project plan. It is closer to a findings memo: what was found, what is still unknown, and a recommended next step (usually a deeper discovery workshop or a narrow pilot scope, not a full build). The value of this document is that it is falsifiable and reviewable by the sponsor before real budget is committed. A sponsor who reads it and disagrees with the framing surfaces that disagreement in week one, when it costs nothing to resolve, rather than in month three, when it costs a rebuild.
Week one framework: diagnose before you build
| Day | Focus | Output |
|---|---|---|
| Day 1 | Systems and access inventory | List of platforms, data sources, existing automations |
| Day 2 | Stakeholder interview schedule set | Calendar booked for sponsor, function heads, frontline staff |
| Day 3-4 | Interviews and shadow-IT discovery | Notes on stated problems vs observed workflows |
| Day 5 | Cross-reference findings against constraints | Compliance, data sensitivity, and infrastructure limits identified |
| End of week 1 | Written diagnosis | Ranked opportunities, risks, and recommended next step (no tool chosen yet) |
FAQ
Does an AI architect need engineering access in week one? Yes, but for reading and mapping, not building. Read access to data warehouses, API documentation and existing pipeline code lets the architect assess feasibility and data quality without committing to any implementation.
Should a company expect a roadmap by the end of week one? No. A written diagnosis with ranked opportunities and open questions is realistic. A roadmap with committed timelines in week one usually means the architect skipped the diagnosis, or is being pressured to produce one before the evidence exists.
What if the business already has a specific tool in mind before the architect starts? The architect should still run the diagnosis. If the tool turns out to be right for the highest-value opportunity, the diagnosis confirms it quickly. If it is not, the business finds out before money is spent, which is the entire point of the role.
How is week one different at a small business versus an enterprise? The process is the same; the scale differs. At a small business, one or two conversations might cover most functions. At an enterprise, stakeholder mapping alone can take the full week, and the written diagnosis may need to be scoped to one business unit rather than the whole company.
What happens if week one reveals there’s no good AI opportunity yet? That is a valid and useful outcome. The diagnosis might recommend fixing data quality or process documentation first. An architect who reports “not yet, and here’s what needs to happen before it makes sense” is doing the job correctly, even though it is not the answer the sponsor expected.
Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.