Karen, our CEO, spent a day at AWS's Executive Forum on building an AI strategy, held here in Singapore, and that knowledge problem sat underneath almost everything discussed. The message for decision makers and practitioners in the room was direct: define the outcomes for the use cases you actually choose, build workflows that let platform agents handle the execution layer, and assemble AI-literate teams alongside all of it, not after.
The knowledge problem manufacturing can't automate away
In established sectors like manufacturing, the human and physical constraint is real. Experienced workers are retiring, and with them goes dense institutional knowledge. Today that knowledge lives in people's heads and in disconnected systems: ERP, PLM, MES, IoT, each holding a piece of the picture, coordinated across teams that rarely talk to each other.
Here's the part worth sitting with: the data and the tools mostly already exist. Many of the use cases are already well understood, because the core business hasn't fundamentally changed. So the question isn't whether the raw material is there. It's what you do with it next.
That's a different starting point than most AI conversations assume. Nobody in the room was asking whether manufacturers have enough data or enough tooling. The ERP, PLM, MES, and IoT systems have been running for years. The gap is that the knowledge connecting them still lives in one person's head, and that person is retiring on a schedule the org chart doesn't control.
What other builders are already doing
A few speakers gave a clear picture of how enterprises are maturing toward what Manuel Baeuml called a "touchless supply chain." Vaibhav Kapur described SAP-native agents built to work inside the systems manufacturers already run. Alvinn Y. talked about capturing institutional context through semantic relationships, effectively giving machines a version of the tribal knowledge that used to live only in a veteran operator's head. Nidhi Gupta framed the governance question as "human-above-the-loop," a useful correction to how loosely that phrase usually gets used.
Start with what won't change in ten years
Picking individual AI use cases can get overwhelming fast. Lily Jang shared a framework that cuts through that: optimize for outcomes that aren't going to change in the next decade, no matter how the technology does. Reducing variation across availability, performance, quality, and inventory. Improving interoperability. Optimizing capacity. Then work backwards from there.
That backward path has a shape: what metric tells you the outcome is being achieved? What data establishes the operational reality behind that metric? What intelligence can you derive from it? What decision needs to be made? What execution follows that decision, and what action actually changes the outcome?
The lineage that keeps agentic AI honest
Outcome, metric, data, intelligence, decision, execution, action. That lineage matters, especially as more of the middle becomes agentic. Without it, it's easy to automate activity without knowing whether the system is producing a better outcome, or why.
It's a version of the same discipline we built into our own I.D.E.A. framework at Human Managed: Intelligence, Decision, Execution, Action. The difference this lineage insists on is naming the outcome and the metric before any of that work starts, not backfilling them once the agents are already running.
Useful intelligence per dollar
One framing from Dale Finlay at OpenAI stayed with Karen: "useful intelligence per dollar." The hard part for every business isn't generating intelligence. It's defining, and continuously operating, what "useful" actually means to them, and what counts as dependable, successful work.
That's the piece that can't be outsourced to a platform, however good the platform is. A vendor can sell you agents that execute faster. Nobody can sell you the judgment call about what "better" means for your business, or the discipline to keep checking that the answer still holds as conditions change.
Where this leaves you
Defining the outcome can't be separated from building the system that produces it. The question isn't whether platform agents can handle the execution layer. It's whether you can state, in writing, what you're asking the outcome to be before you hand it to them.
Thank you to AWS for hosting a genuinely well curated event, and to everyone who shared their thinking on stage and off it.
