iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An AI feature solves a particular workflow in one product; AI infrastructure gives multiple teams a shared foundation they can adapt and improve. In Tom Allen’s 13 September 2026 interview for The AI Journal, Ankit Roy argues that making this shift requires more than reusable code: teams need shared ownership, compatible data, ongoing evaluation, and clear limits on automated action.
What distinguishes an AI feature from AI infrastructure?
Roy describes a feature as a solution shaped for a specific workflow inside one product. “A feature is built for a specific workflow, within the context of that one product. The model is trained and shaped around that use case, so the solution stays tied to it.”
Infrastructure, by contrast, is a framework or library that can support similar workflows across product areas. The practical test is reuse: can another team apply the underlying capability without rebuilding it from scratch, while still adapting it to its own users and context?
That distinction matters because local features can be faster to ship and may fit existing product incentives. But Roy says organizations risk accumulating isolated solutions instead of recognizing patterns that could support several teams. Reuse may create a stronger foundation for improvement, though the interview does not offer comparative performance data or prove that a shared platform is best in every case.
#1 Best Overall
Why do teams get stuck with one-off features?
Local delivery is easier to reward
A product team facing an immediate user problem can often deliver a narrowly scoped feature sooner than it can coordinate a platform intended for several groups. Roy identifies this short-term orientation as a common reason teams build locally.
Shared needs are assumed rather than checked
Two workflows may look similar but differ in data, risk, or user expectations. Roy recommends involving prospective users before implementation and confirming that the need is genuinely shared, rather than designing a central system around an imagined common use case.
Ownership and interfaces are left unclear
Without an agreed owner, common inputs, and output schemas, teams may produce components that are difficult to maintain or reuse. Roy favors an explicit platform ownership model and a foundational layer that consuming teams can extend and help shape.
Recommended Free Tools
How can an organization build infrastructure that teams will reuse?
- Find a real shared pattern. Talk to the teams likely to use the capability and compare their workflows, constraints, and desired outcomes. Build shared infrastructure only where the common need is real.
- Agree on ownership before implementation. Name the team responsible for the foundational layer and establish how users can influence its direction. Roy describes a contribution model in which consuming teams can help shape the platform.
- Align data and interfaces. Define common input data and output schemas where workflows genuinely overlap. Keep room for teams to customize the foundation when their context differs.
- Start with a foundation, not a rigid universal product. Make the reusable layer extensible so product teams can adapt it without fragmenting the underlying capability into unrelated copies.
- Plan for operation and improvement. Treat evaluation, feedback, and monitoring as continuing responsibilities rather than tasks that end at launch.
How should teams set confidence thresholds and human safeguards?
When an AI system moves from recommendations to actions, Roy says teams should first understand the human task, its risks, and why people currently perform it. The appropriate boundary depends not just on model confidence, but also on the consequences of an error and whether an action can be undone.
- Begin with recommendations or human-routed cases. Uncertain cases can go to a person, allowing the system to assist without taking the decision away from the user.
- Consider reversibility and impact. Roy says reversible actions are generally safer to automate sooner. Irreversible actions call for more careful routing and safeguards.
- Expand automation gradually. Test a limited set of high-confidence actions first, then broaden the scope only as evidence supports it. The interview does not prescribe a universal numerical confidence threshold.
- Watch for changing behavior. Use drift detection and human feedback to identify when inputs, user behavior, or operating conditions have shifted.
Roy rejects automation as an end in itself: “I don’t think the goal should ever be full automation for its own sake.” He frames the aim as a sensible productivity improvement within acceptable risk limits.
What should teams measure after launch?
Roy emphasizes whether the system achieves its intended outcomes, not simply whether it runs or produces confident-looking outputs. Evaluation should reflect the task and its context, use ground truth where it is available, and include human evaluation when feasible.
Rank #4
- Define the intended outcome for the workflow before judging system quality.
- Compare outputs with relevant ground truth where a reliable reference exists.
- Use human review where automated evaluation cannot adequately assess the result.
- Set guardrails against harmful outcomes and monitor for drift.
- Revisit measures as scenarios and behavior change, rather than treating launch metrics as permanent.
The interview does not provide benchmark figures, a prescribed evaluation method, or evidence that one metric works across domains. Teams need measures suited to the decision and consequences in their own workflow.
What may differentiate companies as model capabilities converge?
Roy expects contextual integration, proprietary data, safe operation, user trust, and continual measurement and improvement to matter as model capabilities converge. This is his forecast in the interview, not an independently established prediction. His broader product point is that AI alone is not the value proposition: “The real value for a product was never just having AI, it’s still about solving the core user problem, with AI acting as a helper on top of that.”
Source: Tom Allen’s interview with Ankit Roy, The AI Journal, 13 September 2026. The AI Journal. The interview does not state Roy’s job title in the quoted exchange.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
