What did Arm Create 2026 teach developers about moving AI from model to working software?

Decide what infrastructure an agentic application needs

When an application becomes agentic the model is only one part of the challenge. Agents generate code, call tools, and take actions dynamically. This places new demands on the infrastructure underneath them. At Arm Create Shanghai Tencent Cloud's Cube Sandbox provided a concrete example. The discussion covered isolation and concurrency. It also covered security, state, resource management, and cost. The question was which parts of the platform should handle each workload so developers can stay focused on the application. The broader lesson is that agentic applications need a controlled execution environment around the model. Actions, tools, state, and resources can then be managed consistently as the application scales.

Choose the model that fits the workload

Model choice starts with the workload not model size alone. A quick-reply feature in a mobile app pushes model choice one way. A cloud agent reasoning across large document sets pushes it another. An edge vision workload pushes it a third. The Arm Create Shenzhen panel brought this into focus. Alibaba Qwen, ModelBest, Tencent Hunyuan, and Ultralytics joined the discussion. The conversation moved beyond model comparison toward application fit. What the workload needs. Where it should run. How it behaves once deployed. The principle is straightforward. Fit the model to the work then put the work in the right place. The Arm AI Portal helps developers discover models validated and optimized for Arm-based platforms. It helps them understand the target fit and find code and deployment information.

Decide how to measure and optimize the complete application

If an AI experience is slow or inefficient the model is only one place to look. Time and resources can also be spent in the runtime. Data movement and preprocessing take their share. Application logic and underlying compute do too. A voice assistant can lose time in audio preprocessing. A mobile AI feature can hit memory or thermal limits during sustained use. That makes system-wide profiling and optimization part of the development loop. Arm Performix and Arm Performance Studio help developers understand where workloads spend time and resources. Arm Scalable Matrix Extension 2 and neural graphics tooling provide different ways to improve performance on Arm-based platforms. Useful optimization starts with evidence from the workload and the constraint that matters. Response time, power, cost, or sustained performance each demand a different focus.

Decide where each workload should run

Not every part of an AI application belongs in the same place. Developers must decide which workload should stay on device. They must decide which benefits from nearby edge infrastructure. They must decide which requires scale and shared services in the cloud. Compute capability shows where a workload can run. Product requirements help determine where it should run. Latency and privacy shape that choice. Offline operation and local control shape it too. Cost and available compute play their part. A single application can split work across several locations. The goal is not to choose one location for the whole application. The goal is to place each part where its requirements are best met. The Arm compute platform spans those deployment choices across cloud, edge, mobile, and graphics. The AI Portal can help connect model selection to specific Arm-based targets and deployment paths.

Keep the workflow portable then validate on the real target

AI applications rarely stay in one environment. A team might prototype locally. They might test on cloud infrastructure. They might move part of a workload onto a device. Then they optimize for a mobile, edge, graphics, or physical AI target. If the model, runtime, tooling, and performance workflow change completely each time that movement creates more work. At the Arm Create Shanghai fireside Eric Ernst from Aston Martin Formula One Team and Irving Chen from Unitree spoke. They used Formula One cars and humanoid robotics as two examples of the same engineering challenge. In both cases software, hardware, data, sensing, and control must work together. Real world conditions cannot be fully predicted. This makes portability and validation connected problems. Every movement between cloud, edge, mobile, graphics, and physical AI adds friction if the workflow keeps changing. Developers benefit from tools, libraries, models, and workflows that can move with the application. The final proof still has to come from the environment where it will run. The physical AI labs at the Arm Create events extended that idea. They covered simulation-to-robot workflows, deployment, trust, telemetry, and device discovery. SME2, KleidiAI, Performix, Arm MCP Server, neural graphics tooling, Arm Device Connect, and Arm AI Portal each support a different part of that workflow. The practical takeaway is to think about portability early. Keep as much of the workflow consistent as deployment choices change. Validate the complete system on the target that matters.

What the document does not say

Ninety-seven percent of Arm Create Shanghai survey respondents said the event improved their understanding of how to build, optimize, and deploy AI applications on Arm. The document does not say how many developers attended either event. It does not say whether the survey sample represents the full attendee base. The next Arm Create event moves to the US. Developers there can continue working through these same practical questions with Arm experts and ecosystem partners. They can get hands-on with the tools and workflows behind AI applications from cloud to edge. The document does not say when that US event will take place or which cities it will visit.