Production readiness determines whether AI pilots scale, says Harris Farm Markets’ Head of Infrastructure
In this ADAPT Insider episode, Leonard Rawat talks about why AI infrastructure must follow the business case before pilots reach production.AI pilots can create false confidence.
Controlled data, prompts and supervision often make early results look stronger than the systems that eventually reach production.
Leonard Rawat, Head of Infrastructure, Security and Operations at Harris Farm Markets, explains why infrastructure choices must start with the use case.
He examines what changes as token demand grows, why guardrails belong in the architecture and how internal capability turns experimentation into practical value.
Listen to the full episode on Apple Podcasts, Spotify or YouTube.
Key takeaways:
- The use case must determine the infrastructure. Organisations should define the business problem before selecting a platform, model or deployment approach.
- Production readiness starts during the pilot. Security guardrails, cost controls and token optimisation must be designed before workloads scale.
- Business context has to be built internally. Training and sandboxed experimentation help employees turn operational knowledge into useful AI solutions.
Production exposes the weaknesses pilots conceal
Many AI projects perform well in pilots because the data is clean, prompts are controlled and users receive close supervision.
Those conditions disappear when systems enter day-to-day operations.
Leonard says organisations should plan for scale from the outset.
Token consumption can rise quickly as experimentation develops into agentic workflows or automation, increasing pressure on the platform and its operating cost.
The AI platform must align with data location, expected demand and the original business case.
Infrastructure choices determine whether a promising pilot can deliver reliable value in production.
Guardrails have to be part of the architecture
AI infrastructure extends beyond keeping systems available.
It must account for cloud spend, token usage, security exposure and the wider ecosystem surrounding each model.
Leonard argues that clear controls are needed at the infrastructure layer before deployment expands.
Sandboxed environments give teams room to test ideas without exposing production systems, while token optimisation helps contain costs as usage increases.
Embedding these controls into the architecture supports confident scaling.
Without them, risk and expenditure can grow faster than the value created by the technology.
Internal capability turns business context into value
At Harris Farm Markets, employees across marketing, finance, procurement and warehouse functions can use sandboxed environments, training and accessible development tools to build prototypes safely.
Leonard points to practical applications ranging from Shopify workflows to security vendor mapping.
People closest to an operational problem can test a solution in a controlled environment, shortening the distance between an idea and a useful outcome.
Organisations cannot buy their own business context.
They need people who understand the work, supported by the tools and governance required to apply that knowledge.