Mimik and AMD Advance Device-First Agentic AI for Physical Systems

In this exclusive interview with Semicon Leaders Asia, Fay Arjomandi, Founder, CEO and Board Member of mimik, shares how mimOE Embedded Edition and AMD’s Ryzen AI Embedded X100 Series are shaping a device-first approach to Agentic AI, enabling secure, scalable and efficient intelligence for physical AI, autonomous systems and industrial automation.

Q. mimOE Embedded Edition has been designed for AMD's Ryzen AI Embedded X100 Series. What does the combination bring to physical AI, autonomous systems, and industrial automation that existing AI deployment platforms cannot offer?

Automation built on agentic workflows needs many agents, each expert in its own area, working together to complete a task. They run in different places: on endpoint devices, on a local server, and in the cloud. A device like the X100, an embedded processor with CPU, GPU and NPU cores on one chip, hosts many agents itself and needs to reach agents on phones, tablets and machinery to finish the workflow. Keeping the device first while agents spread across those tiers is what we call Device-First Continuum AI and Compute.

This agentic architectural approach requires several capabilities at once: agent discovery, an identity each agent can prove separately from the user who launched it, authorisation checked at the moment of action, workload placement, execution, and an audit trail, all of it working on the hardware with or without any connection to the cloud. Existing platforms cover parts of it. Cloud management systems built for data centres handle identity and permissions well and assume a reliable network and a central controller that agents check with before acting. Inference runtimes run models efficiently on local silicon but have no concept of several agents working with one another. mimOE, the mimik Agentix Operating Engine, runs on any compute device and provides all of these capabilities in one platform.

Each capability is harder on real hardware than it sounds. Agent discovery has to work across different makes of device and different operating systems, because real deployments mix them. Starting and moving work has to be fast, since agents are created and retired constantly and a workflow in progress sometimes has to move machines. Agents and the services they call run as microservices on mimOE, which start in a fraction of the time a container or a virtual machine takes.

mimOE hosts the components a workflow needs as microservices. An API gateway lets agents reach outside services, an MCP server lets them use tools through a standard interface, retrieval-augmented generation lets an agent consult a document store, and mesh networking lets agents reach each other directly. Without mimOE, a team assembling these from separate products must spend its effort integrating them before building any application and then has to keep every capability current as each supplier releases on its own schedule. The integration is done once, but the maintenance continues for the life of the deployment.

mimik has built mimOE on the platform it pioneered and production-hardened over the past decade. Those principles remain valid: run the workflows as microservices on any compute device regardless of their place within the continuum (endpoint, edge, cloud), enable agents to

mimOE also enforces a zero-trust architecture, so agents interact on the basis of verified identity and per-action authorisation rather than on network placement. Agent-to-agent security therefore does not depend on perimeter controls, and a compromised agent cannot reach anything it has not been individually authorised for.

On the X100, mimOE takes advantage of a balanced architecture: a high CPU core count and shared memory. Most of what a running multi-agent system does is coordination rather than inference, and coordination is what demands CPU, which makes the X100 a good match. Shared memory lets the CPU and the accelerator read the same data instead of copying it between them. mimOE is available for download across all major silicon families, and mimOE Embedded Edition was built with AMD, adding tools and tuning for the X100.

Q. Your analysis shows that more than 80% of multi-agent AI workloads are handled by the CPU rather than the GPU. How does this finding reshape the way OEMs and enterprises should architect next-generation Agentic AI systems?

The 80 per cent describes operations, not time. In the agentic workflows we traced, more than 80 per cent of operations were CPU work: service discovery, inter-agent collaboration, security checks, data movement, routing, and lifecycle management. Under 20 per cent were model inference. The exact mix varies workflow by workflow, and Agentix Benchmarking, downloadable for the X100, lets teams measure their own workloads directly on the silicon. Running the models still accounts for most of the elapsed time, and the GPU is essential for that, but the inference delegated to the GPU is only one part of an agentic workflow.

Those CPU operations decide how far a deployment scales, because the CPU has to run them for every agent working at the same time. Every inter-agent call carries real CPU cost on both the sending and receiving side: serialisation, transport, zero-trust checks such as mutual TLS and signature validation, and routing. A single workflow handles that easily. Dozens at once do not, and a device sized only for inference speed runs out of CPU to schedule, secure and move data long before the GPU is anywhere near fully used. That is why a balanced platform like the X100 sustains substantially more concurrent agents than a GPU-centric one on the same workload.

Multi-agent systems have to evolve as workflow requirements change, so the platform architecture has to be flexible from the outset. Performance, latency, economics and privacy all point the same way: start at the local device, where the richest context sits and where the action is taken, which is what Device-First means in practice, and treat the cloud as the last step, used only when required. That means choosing balanced hardware, with plenty of CPU and memory and enough GPU and NPU capacity for the models the workflow runs, then ensuring that more compute of any kind, CPU, GPU or NPU, can be added and clustered in with zero configuration. Adding compute has to stay possible once the deployment is live, because an operator will rightly refuse a change that requires reconfiguring every device in a running plant. The alternative is provisioning on day one for a peak that may never occur, which is wasteful.

That flexibility requires several properties working together. Agents must run as serverless microservices, started when needed and stopped afterwards, so a device holds no idle capacity for agents it might eventually run. They must call each other through the same API whether the agent being called is on the same device or another one, which is what lets work move between devices without anything being rewritten. Models must be shared in memory rather than copied for each agent, so agent count is not limited by duplicate weights. Data must stay on the device that produced it, so work can be placed according to where the data is permitted as well as where compute is free.

Q. One of mimOE's key differentiators is its ability to load shared AI models once and reuse them across multiple agents and tenants. How does this improve memory efficiency, reduce hardware costs, and enable larger AI deployments on existing edge devices?

Two independent mechanisms reduce memory use. The first is running agents as serverless microservices, so they consume memory only while they are active. Otherwise, every agent would have to sit in memory whether or not anything had called it. The second is loading models once and sharing them, so the memory that active agents do consume depends on how many distinct models are running rather than on how many agents use them.

The benefit of the second mechanism is easy to quantify. In a normal deployment, each agent loads its own copy of the model it uses, so ten agents using one 4 GB model take up 40 GB between them. Run several production lines on the same device, each with their own agents, and the total multiplies again. This is what limits multi-agent deployments on embedded hardware, however fast the processor's AI accelerator is. mimOE loads each model once and lets every agent work from that single copy, so adding an agent only uses the working memory that agent needs while it runs. Sharing does depend on agents using the same model, and two lines running differently tuned versions of a model need a copy each.

We modelled a clinical hub to show the size of the effect. Serving fifteen patients at once, loading models per agent needed about 136 GB, which exceeded the 128 GB ceiling. Run as microservices, the same workload used about 14 GB. Extending the model across a fleet, three devices carried 435 patients with mimOE against 42 without, and ten devices carried 1,850 against 140. The example comes from healthcare, and the numbers work the same way for a plant running multiple production lines from one controller.

Running everything as microservices also provides significant benefits for updates and maintenance, which matter as much as the memory saving over the life of a product. Everything a workflow uses is a microservice, including the small ML models it calls, and each one is versioned and updated on its own. With mimOE, a new release of an agent, of a small model running on the device, or of a workflow that calls a larger model elsewhere does not require a coordinated update of the whole system. As for models, since there is a single copy on the device, they can be updated in one operation rather than one per agent, and no agent is left running an old version because its own copy failed to update.

Q. Many AI projects struggle to move beyond proof-of-concept. How does mimOE Embedded Edition help OEMs, system integrators, and enterprise customers accelerate the transition from pilot projects to production-scale Agentic AI deployments?

The industry has solved intelligence and compute; it has not solved operationalization, and that is where projects stall. A proof of concept shows that the technology works, usually with one agent doing one task in a controlled setting. Even when it succeeds, projects stop there, because a PoC leaves too many operational questions unanswered to convince the people who will have to run the system. Most real workflows need several agents working together to finish a single task, and that is what the operations team needs to see.

Within real operations, one agent's result may become another agent's input, work may have to move between agents on different devices, and the whole sequence must finish within a time the operation can accept. Corner cases must be handled too: an agent that is busy or unavailable, a step that fails halfway through, or an agent that tries to reach data outside its own job. A single agent answering a single question shows none of this, and it shows none of what production requires either: identity and authorisation per agent, actions recorded in the monitoring the operations team already runs, working updates and rollback, and continued operation when the network is down.

mimOE, the mimik Agentix Operating Engine, provides all of these capabilities from the first day of a project: agent discovery, workload placement across devices, an identity each agent can prove, authorisation on every action, an audit trail that goes into the monitoring already in place, and update and rollback for agents in the field. The team can then focus on what actually matters to their customer, which is designing the workflow logic on top of the platform. Without mimOE, a team building on an inference runtime has to build that infrastructure from scratch, for each project, against a deadline, while also building the workflow. That infrastructure often takes longer than the workflow design, and it is where the unknowns are, which is how these projects overrun and miss their deadlines.

With mimOE, the proof of concept, the pilot and the production deployment are the same system. A developer builds on a laptop, and the same software runs on the deployed X100, so nothing has to be rebuilt at either step. Serving several production lines from one device follows from the same design, since agent identity already keeps one line's agents and data apart from the others.

Agents on the device handle what the device resources can handle. When a task needs a larger model than the device can run, the agent sends that task to a cloud model. Escalation of this kind is part of the design. Local execution is the default; the operator sets the rules for when a task goes to the cloud, and if the connection drops, the agents keep working on everything they can do locally. That is the path mimOE Embedded Edition provides: from PoC to scaled operations with certainty.

Q. The platform combines multi-agent choreography, zero-trust security, dynamic service discovery, and multi-cloud integration. Which of these capabilities are customers prioritising today, and how do they address real-world deployment challenges in industrial environments?

It depends on the use case, and specifically on what limits that deployment. Multi-agent choreography, zero-trust security, dynamic service discovery and multi-cloud integration come in a different order depending on that limit, and no single one is always the priority across sectors.

Where connectivity is the limit, multi-agent choreography comes first. A maritime deployment on a weak satellite link is the clearest case, since the connection is intermittent and expensive and any decision needing a round trip fails when the link drops. Those agents still have to be updated regularly and doing that over a poor link is harder than running them. A central coordinator has to be reachable to change the agent set or their versions, and the change has to be applied consistently across the whole system. With choreography, each agent carries its own policy and announces itself to its peers, so agents are updated one at a time over whatever bandwidth is available and the rest of the system adapts without a fleet-wide operation.

Where the data is sensitive, zero-trust security comes first, meaning every agent is identified and isolated. An agent acting with the credentials of the person who launched it cannot be audited, because nothing in the record separates what the agent did from what the person did. Agent identity, authorisation on every action, and an audit trail of every action are what allow a security review to finish and a deployment to proceed.

Where cost is the limit, token pricing decides it. A workflow where agents exchange many messages to reach one result produces a large per-token bill in a cloud-centric deployment, while the same workflow on hardware the operator already owns costs nothing extra per call. Escalation to cloud models remains available for tasks that need it, so the operator pays for the exceptions rather than for every interaction.

Where fleets are large, service discovery matters most, and it matters more when the fleet comes from several suppliers. Configuring each connection by hand is workable at pilot scale but becomes the largest maintenance cost at fleet scale, particularly where devices join, leave and change roles between shifts. No one supplier's console covers the whole fleet, and the devices differ in capability. With dynamic service discovery, agents advertise what they can do and find peers able to take the work, so adding a device from a new supplier does not require rewriting the deployment.

In our experience, multi-cloud integration is asked about early and exercised later: most first deployments run on a single cloud, and the capability appears in procurement as protection against lock-in, foundational rather than a day-one decision point.

One caveat applies to all of this. Physical AI deployment is still at an early stage and the installed base across the industry is small, so the pattern above comes from our own engagements and those of our partners rather than from a large population of production systems.

Q. As Agentic AI adoption accelerates across manufacturing, robotics, and autonomous systems, what is mimik's long-term product roadmap, and how do you see the partnership with AMD evolving to support increasingly complex edge AI workloads?

mimOE already runs on every major operating system. We keep those versions current and add support for new operating systems as they appear, which happens regularly in embedded and client platforms. Customers inherit that work rather than carrying it, which is part of what they are buying. We also keep building microservices that give agents new capabilities, and that library grows continuously. Where a workload justifies it, we work with silicon partners on tighter integration to make specific workflows faster, and we provide the services around that integration. mimOE is downloadable and runs on hardware as shipped.

Robotics and autonomous systems set the hardest version of the requirement. A manufacturing analytics workload tolerates a late answer; a machine that moves does not, and the delay accumulates in the coordination steps rather than in the model calls. Reducing the number of steps a result needs, and the time each one takes, is where most of our engine work goes, and our team is expanding the microservice library and tools to address it.

On AMD, we do not pre-announce partner roadmaps. The published arc speaks for itself: the platform collaboration announced in June 2025, and mimOE Embedded Edition with Agentix Benchmarking downloadable for the X100 today. The Device-First Continuum runs from embedded hardware through client PCs to cloud and server, and AMD has products at every one of those tiers. An agent that starts on an embedded device often needs compute it cannot get locally, and it has to reach a PC, a server or a cloud service without the rules governing it changing along the way. mimOE provides that consistency across the continuum: the same operating engine on every tier, the same API whether the agent being called is local or in a data centre, and identity and authorisation that travel with the agent.