Starting From Zero: The Founding Sequence for a Cloud, AI, or Agentic AI Practice That Doesn't Exist Yet

*Series: Building the AI-native enterprise — a practitioner's playbook for scaling Cloud, AI and Agentic AI practices*

*Post 3 of 10 | aiorbitx.com*

*Industries covered across this series: BFSI, healthcare, pharma, manufacturing, retail, logistics.*

01 — Executive hook

Every Greenfield organization I've helped start a practice — customer or IT firm — makes the same first move: they hire a specialist before they've earned the right to need one.

A senior ML engineer with no pilot to work on. A prompt engineer with no governance to operate inside of. A platform architect with no use case to anchor the architecture to. The hire feels like progress. It isn't. It's a signal that the founding sequence got skipped.

The founding sequence in this post exists because the first hire, the first pilot, and the first governance artifact have to happen in a specific order, or none of them stick. Get the order right, and the second pilot is dramatically easier. Get it wrong, and you'll be relitigating the first one for a year.

02 — The problem

Three mistakes account for almost every stalled Greenfield practice I've seen, across every industry:

Platform before proof. Teams buy or build infrastructure sized for a program before they've delivered a single pilot that earned executive trust. The platform sits idle. The budget conversation becomes defensive. The practice lead spends their first six months justifying the infrastructure spend instead of shipping something.

Specialist before translator. The first hire is often a technical specialist who can't explain results to a business sponsor — or a business lead who can't scope what's technically real. Neither can recruit the next hire with judgment. The founding team ends up lopsided, and the gap shows up in the first steering committee.

Governance as an afterthought. Especially in BFSI, healthcare, and pharma, governance gets treated as a blocker to route around rather than the artifact that makes the second pilot possible. The first pilot ships without a data use policy. The second pilot gets killed by legal. The practice loses six months it didn't have.

These three mistakes aren't random. They're the predictable result of starting with the wrong question. Most Greenfield practices start by asking "what should we build?" The right question is "what do we need to earn the right to build anything at all?"

03 — The maturity question

This post is for you if you scored L1 across most dimensions in the Post 1 self-assessment, or if Post 2 placed you as Greenfield on either side of the relationship.

The question at this stage isn't "where are we" — Posts 1 and 2 already answered that. The question is: what do we build first, and in what order?

One honest check before you read further: if your organization already has a funded cloud practice with a real CoE, this post isn't your starting point — Post 4 is. The founding sequence here is specifically for organizations that have nothing formal yet: no CoE, no repeatable delivery pattern, no governance cadence. If you have any of those things, even informally, you're Cloud-anchored, not Greenfield, and the sequence changes.

04 — The framework: the founding sequence

Five steps, largely sequential, taking roughly 90 days end to end. The sequence is not a project plan — it's a credibility-building arc. Each step earns the right to take the next one.

Step 1 — Sponsor and charter (1–2 weeks)

One accountable executive sponsor. Not a steering committee, not a working group, not a "champion" who attends meetings. One person whose name is on the charter and whose credibility is attached to the outcome.

The charter is one page. It names three things: the scope of the founding sequence (not the program — just the founding sequence), the explicit non-goals (what this initiative will not try to do in the first 90 days), and the single metric that defines early success. One metric. If you can't agree on one metric, you don't have a sponsor — you have a committee.

The charter gets ratified before any hire is made and before any tooling is purchased. This is the hardest constraint to hold. Resist it.

Step 2 — First hire (2–6 weeks)

One practice lead. Bilingual across technical and business language — a translator who can explain a model's output to a CFO and scope a delivery sprint with an engineer in the same afternoon.

This is not a senior ML engineer. It's not a project manager. It's a specific profile that's genuinely rare: someone who has shipped something real in an AI or cloud context, can recruit the next two hires with judgment, and is comfortable operating without a playbook because there isn't one yet.

The founding team this hire builds is three people total: the practice lead, one delivery engineer capable of shipping the pilot alone if needed, and one business analyst embedded from the sponsor's team. Resist adding a fourth hire before the first retrospective. The instinct to staff up early is the platform-before-proof mistake applied to headcount.

Step 3 — First pilot (6–8 weeks)

One narrow, visible, low-risk use case. Fixed timeline. Capped budget. The goal is trust, not scale.

"Narrow" means one process, one data source, one team. "Visible" means the sponsor can see progress weekly, not just at the final readout. "Low-risk" means the failure mode is embarrassing, not catastrophic — a pilot that fails in a regulated environment without a governance artifact in place is not low-risk, regardless of how small the use case is.

Weekly demos to the sponsor, not just a final readout. If the pilot isn't visibly on track by week 4, cut scope rather than extend the timeline. A six-week pilot that ships something small is worth more than a ten-week pilot that ships something impressive — because the six-week pilot proves the practice can operate on a cadence.

Industry-specific note: in healthcare and pharma, the use case selection at this stage is constrained by GxP and HIPAA boundaries even for a pilot. In BFSI, model risk management requirements apply from the first production-adjacent test. Build the governance artifact (Step 4) before the pilot touches any regulated data or process — not after.

Step 4 — First governance artifact (parallel to Step 3)

A single page. Three sections: data use (what data the pilot touches, who approved it, and what the retention and deletion policy is), model risk (what the model does, what it doesn't do, and what the human-in-the-loop checkpoints are), and escalation (who decides if the pilot needs to stop).

This artifact gets ratified — by the sponsor, by legal or compliance if required — before pilot results are presented. Not before the pilot starts. Before the results are shared. The sequence matters: the artifact is what makes the results shareable.

This is the governance artifact that makes the second pilot possible. Without it, the second pilot gets killed by the same legal and compliance review that should have happened the first time. With it, the second pilot has a template to extend rather than a process to invent.

Step 5 — First retrospective (1 week)

A structured review of three questions: what worked, what it cost, and what a funded L2 charter requires.

"What worked" is not a celebration — it's an honest accounting of which parts of the founding sequence held and which were improvised. "What it cost" is the actual number, not the budgeted number, and it becomes the baseline for the L2 budget conversation. "What a funded L2 charter requires" is the output: a one-page brief that names the next three hires, the next two use cases, and the governance cadence the practice needs to operate at L2.

The retrospective is what earns the larger budget. Not the pilot results — the retrospective. A pilot that succeeded without a retrospective is a one-time event. A pilot that succeeded with a retrospective is the first data point in a practice.

05 — Operating model *(tactical here; full treatment in Post 6)*

At this stage, don't design a target-state operating model — you don't have enough evidence yet to know what you need.

Use a lightweight, temporary hub: one team, one backlog, one decision-maker. The practice lead owns the backlog. The sponsor owns the escalation path. There is no governance forum yet — the charter and the governance artifact are the governance.

If both customer and firm are Greenfield (Position 1 from Post 2), form a joint founding council instead of two separate hubs. One shared backlog, one shared retrospective, one shared governance artifact. The instinct to run parallel tracks is the operating model equivalent of platform before proof — resist it.

Post 6 maps the full operating model evolution from this temporary hub through to a federated CoE, with the specific triggers that tell you when to move from one to the next.

06 — Organization

The founding team is three people, not a department.

The practice lead owns the founding sequence end to end. They write the charter, make the first hire (themselves), recruit the delivery engineer and business analyst, run the pilot, and write the retrospective. They are accountable for the outcome of the 90 days.

The delivery engineer ships the pilot. One person, capable of doing it alone if the team shrinks. They are not a platform architect, not a data engineer, not a solutions architect — they are someone who can take a scoped use case from brief to demo in six weeks with the tools available.

The business analyst is embedded from the sponsor's team. They own the use case definition, the success metric, and the weekly demo narrative. They are the bridge between the pilot and the business — and they are the person who carries the practice's credibility into the sponsor's organization after the retrospective.

Resist adding a fourth hire before the first retrospective. Every Greenfield practice I've watched add a fourth person before the retrospective has regretted it — not because the person was wrong, but because the team didn't yet know what they needed.

07 — Delivery

Run the first pilot as a fixed-scope, capped-timeline engagement — 6 to 8 weeks, non-negotiable.

The fixed timeline is not a project management constraint. It's a trust-building mechanism. A pilot that runs to a fixed timeline, even if it ships less than planned, proves the practice can operate on a cadence. A pilot that extends its timeline, even if it ships more than planned, proves the practice can't hold a commitment. The sponsor remembers the second thing longer than the first.

Weekly demos to the sponsor. Not status updates — demos. Something running, something visible, something the sponsor can react to. If the demo at week 4 shows the pilot is off track, cut scope rather than extend the timeline. A smaller pilot that ships on time is worth more than a larger pilot that ships late.

08 — Technology

Resist tool sprawl at this stage. One cloud landing zone. One model or agent framework. One observability tool. That's the entire stack for the founding sequence.

The instinct to evaluate platforms, compare frameworks, and build a reference architecture before the first pilot is the platform-before-proof mistake in technical form. The founding sequence doesn't need a reference architecture — it needs a working pilot. The reference architecture comes out of the retrospective, informed by what the pilot actually required.

Regulatory context applies even at Greenfield stage. HIPAA and GxP evidence trails in healthcare and pharma — even a pilot that touches patient-adjacent data needs a data use policy before it runs. PCI DSS and RBI/SOX-class controls in BFSI — even a proof of concept that touches transaction data needs model risk documentation. OT/IT boundary governance in manufacturing — even a pilot on the IT side needs to document what it doesn't touch on the OT side.

09 — Economics

Illustrative planning bands, not quotes — actual figures vary widely by industry, region, and organization size.

A Greenfield founding sequence is typically funded as a single seed initiative, not a program budget. It is usually the smallest single line item the practice will ever request. The founding team of three people, a capped pilot budget, and a governance review is a rounding error in most enterprise budgets — and that's intentional. The ask is small enough that a skeptical CFO can approve it without a business case. The retrospective is what earns the larger, cost-center-level budget covered in Post 8.

The economic argument at this stage is not ROI. It's optionality. The founding sequence buys the organization the right to have a real budget conversation in six months, with evidence instead of projections.

10 — Business

The value narrative at this stage isn't ROI — it's credibility.

A successful founding sequence proves three things: the practice can ship something real, it can be governed responsibly, and it knows what it needs next. Those three proofs are worth more than any projected return on a pilot that hasn't shipped yet.

The credibility narrative is also the right narrative for the sponsor. A sponsor who approved a founding sequence that shipped on time, within budget, with a governance artifact in place, and a clear retrospective brief — that sponsor has something to show their peers. That's the business value at this stage: a sponsor with a story to tell.

11 — Roadmap

• Days 1–30: Steps 1 and 2 — secure the sponsor, write the charter, make the first hire. These two steps are the prerequisite for everything else. Nothing else starts until both are done.
• Days 31–90: Steps 3 and 4 in parallel — run the first pilot, ratify the governance artifact. The governance artifact must be ratified before pilot results are presented, not before the pilot starts.
• 6 months: Step 5 complete, L2 charter drafted, second pilot scoped. The retrospective output is the input to the L2 budget conversation.
• 12 months: Practice operating at L2 — reusable templates emerging, governance forum on a defined cadence, second pilot shipped or in flight.
• 24 months: A realistic ceiling is L3 for organizations that executed well. Getting there sooner usually means the founding sequence was rushed, not accelerated — and the shortcuts show up in the governance layer first.

12 — Executive checklist: what a CIO/CTO should do Monday morning

☐ Name one accountable executive sponsor — not a committee, not a champion, one person whose name is on the charter

☐ Write the one-page charter before approving any hire or tooling spend — scope, non-goals, one success metric

☐ Hire a translator, not a specialist, as the first practice role — bilingual across technical and business language

☐ Pick a pilot you'd be comfortable being small — narrow, visible, low-risk, fixed timeline, capped budget

☐ Draft the governance artifact in parallel with the pilot, not after it succeeds — data use, model risk, human-in-the-loop

☐ Hold the founding team at three people until after the first retrospective — resist the instinct to staff up early

☐ Run the retrospective as a structured brief, not a celebration — what worked, what it cost, what L2 requires

13 — Quick check

One-question self-check: does your organization currently have a named executive sponsor for its AI or agentic AI practice — one person, accountable, not a steering committee?

If the honest answer is no, that's Step 1, and everything else in this post waits on it. Not because the other steps aren't important — they are — but because without a named sponsor, the charter has no owner, the first hire has no mandate, and the pilot has no escalation path. The sponsor is the load-bearing constraint of the founding sequence.

The full self-assessment, with automatic scoring across Cloud, AI/ML, and Agentic AI, is in the Post 1 companion workbook — Practice Maturity Self-Assessment.xlsx.

14 — Closing thought

Every Greenfield practice I've watched succeed did these five things roughly in this order. Every one I've watched stall skipped or reordered at least one of them.

The sequence isn't arbitrary. The sponsor earns the right to make the first hire. The first hire earns the right to run the first pilot. The governance artifact earns the right to share the pilot results. The retrospective earns the right to ask for a real budget. Each step is a proof that the next step is worth taking.

Go in this order, and the second pilot gets dramatically easier. Go out of order, and you'll be relitigating the first one for a year.

*Next in the series — Post 4: Integrating AI Into an Existing Cloud Practice — the far more common starting position: organizations that already have cloud maturity and need to bolt AI on without rebuilding what already works.*

*Sai Bharat Sripathi is a technical leader and enterprise AI architect building and scaling Cloud, AI/ML, and Agentic AI practices across BFSI, healthcare, pharma, manufacturing, retail, and logistics. This is Post 3 of a 10-part series on aiorbitx.com.*