Agentic AI in Edge Software Applications: Workflow Steps, Limits, and Review Practices

Edge AI applications succeed only when a model, compiler, runtime, testbench, and physical device constraint become one usable engineering path. Instead of treating code generation as the final outcome, a practical workflow treats each step as an artifact that must be selected, checked, and made traceable. Agentic AI can support that process by connecting existing engineering tools around a target platform.

Intelligent agentic workflows automate the edge AI development stack, accelerating model building, deployment, and management at the edge. (Source: Adobe Stock)

Where application teams can insert agents

Embedded development usually begins with a requirement that has both software and physical consequences. A usable edge AI application may require quantization or compression to match available memory, compilation for a selected processor, integration with a runtime, and validation for latency, power consumption, accuracy, and interaction with surrounding embedded components. Those stages are often carried out with separate tools and manual handoffs.

An agentic workflow changes the sequence by letting a development agent interact with compilers, test frameworks, profilers, debuggers, documentation, and other engineering tools to decide the next step. That coordination can shorten a cycle that once depended on repeated manual effort. Embedded systems, however, create a difficult boundary for this kind of automation. As an agent moves deeper into deployment, optimization, and hardware integration, it needs a stronger understanding of the target system before its results can be checked and trusted.

Speaking with Embedded.com, Vinesh Sukumar, who leads the AI and machine-learning product management team at Qualcomm Technologies Inc., described the present edge AI development workflow. He noted that much of the process still proceeds step by step, from quantization and compilation to runtime selection.

Step-by-step pattern for an application workflow

1. State the application objective in measurable terms, such as target device, accuracy expectation, memory budget, latency window, and power envelope.
2. Collect the existing engineering inputs: requirements, source or model files, build-system configuration, documentation, logs, and prior test output.
3. Let the agent propose a tool sequence that may include model preparation, quantization, graph optimization, compilation, runtime selection, deployment, or diagnosis.
4. Execute the sequence through available toolchains and return concrete artifacts, logs, metrics, and candidate binaries or configurations.
5. Compare the output with expected performance data and with the constraints of the selected hardware.
6. Send ambiguous or safety-relevant results to an engineer for architecture, hardware-behavior, and final verification review.

Platform tools and real workflow examples

For moving generative AI models onto Qualcomm platforms, Qualcomm AI Hub provides developers with tools. It can be used to prepare models from open-source repositories for supported devices and to evaluate performance on the target hardware.

Qualcomm AI Hub supports model preparation, optimization, and evaluation on supported hardware. (Source: Qualcomm Technologies Inc.)

AI Runtime is another Qualcomm offering, using optimized libraries and operators to execute models across its compute engines. Sukumar said the company is working toward an agentic layer that can automate more of the quantization, compilation, runtime selection, and deployment process.

Instructions such as precompiling a model for a target device, optimizing it for performance, and coordinating the software tools needed to find that result could be handled by an agentic workflow. Rohini Ramegowda, a firmware engineer at Torus Inc. who works on safety-critical embedded and real-time systems, told Embedded.com that she already uses a narrower version of this workflow in firmware development.

In her workflow, Ramegowda uses an AI agent that reads the requirements she has prepared, employs a MathWorks MATLAB MCP server to build a MATLAB and Simulink model, generates unit tests from an existing template, and runs the simulation. She manually reviews the resulting model against the requirements.

Earlier, she had to identify suitable Simulink blocks herself, consult MathWorks documentation when needed, and add them manually. “That used to take weeks,” she said. “Now it generates it in hours. But the review part remains the same.”

Diagnosis also benefits when the agent can work across artifacts. In one example, Ramegowda supplied an agent with a configuration binary, the script that generated it, and the codebase after a device began reporting a large number of faults. The agent mapped the binary data back to the firmware structures and identified a mismatch within minutes.

These examples show where much of today’s acceleration comes from: linking engineering steps and information that already exist. The problem becomes harder when those decisions depend on the behavior and constraints of physical hardware.

Hardware limits make context essential

An edge-constrained device workflow cannot always be navigated independently by current agentic AI tools. These devices face limits on memory, storage, bandwidth, compute capability, and power consumption.

The available processor also determines which numerical formats and model operations can run efficiently. A model that works on one system, for example, would need different quantization, compilation, and runtime choices on another.

For larger generative AI models, this point is especially important. Sukumar explained that moving from a 16-bit model to INT8, INT4, or even lower-precision formats reduces the memory and storage required. Hardware support matters equally, with dedicated neural processing units (NPUs), memory architectures, and power management techniques determining whether the resulting workload can deliver the required performance.

When deploying or porting a model, agentic workflows use this hardware information. Sukumar said an agent would first have to identify characteristics such as the target system-on-chip memory, storage, and bandwidth. It could then retrieve the associated configuration and create binaries optimized for that hardware.

Porting is not simply reproducing the same model binary on another processor. Quantization, graph partitioning, compilation, and runtime configuration must all change to meet the target hardware performance limits.

The difficulty rises closer to the hardware. Ramegowda noted differences in drivers, hardware abstraction layers, linker scripts, and memory configurations between controllers. “I wouldn’t think it would be completely autonomous,” she said.

When common interfaces already exist, application-level software is easier to move. Adapting the hardware abstraction layer, however, requires more knowledge of the specific controller.

This is visible in practice through Ramegowda’s work with STMicroelectronics’ STM32N6 microcontroller. She used an agent to help bring up the board, configure an embedded Rust toolchain, and resolve boot and flashing problems. Even getting to a flashed “Hello World” program took roughly a week with adjustments. More importantly, deciding how NPU inference should share the processor with a deterministic control loop remained a manual architecture decision.

The path can be automated more by agents when the hardware is exposed through well-defined tools and interfaces. Abstraction begins to fall apart at hardware-specific architecture.

Review becomes the application bottleneck

As agents generate more code, models, tests, and configuration files, the engineer must determine that the implementation behaves correctly within the complete embedded system. Faster generation can also create more material that needs to be reviewed.

This is visible directly to Ramegowda in safety-critical firmware development. When she writes code herself, she already understands the assumptions and architectural decisions behind it. AI-generated code, however, requires her to reconstruct those assumptions during review.

“The work shifts into review,” she said. “There may be much more code to review because every piece of generated code has to be reviewed.” This includes checking whether the agent accessed the correct memory region or placed functionality in the appropriate deterministic or nondeterministic layer.

Verification includes functional behavior, but it is not the only part. Safety-critical software must also follow the required development process and coding rules. Ramegowda said she checks whether generated code conforms to standards such as MISRA and if the required engineering process has been followed.

Reviewing and correcting an agent’s output can take more time than writing the code manually would have in certain cases. Static analysis, unit tests, simulation, processor-in-the-loop, and hardware-in-the-loop testing provide additional information. No single test, however, establishes that generated embedded software is safe under every operating condition.

A similar verification problem appears in edge AI deployment: a model that is successfully compiled and running on the target does not show that it is using the hardware efficiently.

Sukumar said developers need an anticipated performance range for the target platform, including measures such as memory and energy consumption.

When the result from an agentic workflow falls outside the range, the deployment or its configuration needs work. Without such a reference, it is difficult to determine whether the results show the hardware’s attainable performance.

Implementation time is shortened by agentic AI, and edge AI deployment accelerates if engineers can also verify the generated output efficiently.

Common misconceptions

• Agents can replace every embedded engineering step. The evidence from platform and firmware work is narrower: current gains often come from connecting existing engineering artifacts and automating limited steps.
• Generated code that compiles is ready for deployment. A binary may compile and run while still being inefficient for memory, power, determinism, or safety requirements.
• Porting is a simple copy-and-rebuild task. Quantization, graph partitioning, compilation, and runtime configuration can all need target-specific changes.
• Review can be delegated as easily as generation. In safety-critical work, generated output increases the review burden because assumptions must be reconstructed and standards must be checked.
• More capable tools alone will create autonomous edge development. End-to-end autonomy also needs engineering infrastructure that agents can use, inspect, and trace.

Action suggestions for teams adopting agentic AI

1. Begin with artifacts the team already has: requirements, model files, build configuration, tests, logs, documentation, and expected performance ranges. The clearest application value appears when agents link these inputs instead of inventing new ones.
2. Choose one bounded workflow first. Quantization, compilation, runtime selection, deployment, diagnosis, or test generation may be treated as a candidate for agent assistance, but hardware access and system-level safety decisions should remain under stronger verification.
3. Connect the agent to the toolchain that produces feedback. Sukumar points to compilers, profilers, debuggers, logging systems, documentation, and expected performance data as the foundation for an agentic workflow. If a model fails to compile, for example, only reporting the failure does not help the developer. The agent needs more log history and diagnostic information to identify the cause, locate the documentation, and determine what action to take next.
4. Make the long-term target tool interoperability, not autonomy alone. The longer-term goal, Sukumar said, is to build an agentic layer that can work across existing engineering tools, including profilers, debuggers, and logging systems. The agent would use feedback from those tools to diagnose problems, retrieve information, and determine what action to take next.
5. Match delegation to risk. Ramegowda is comfortable assigning agents for test generation, scripts, tooling, documentation, exploratory analysis, and some non-safety-critical application code. Hardware access and system-level safety decisions still require stronger verification.
6. Plan for human oversight during adoption. Sukumar expects human involvement to decrease as the tools mature. “I don’t think it’s going to be completely zero,” he said. The likely progress is therefore toward greater autonomy: tools provide clear context and feedback, while engineers retain control over hardware, hardware behavior, and final verification.
7. Treat infrastructure maturity as the enabling condition. “I’m pretty confident that the infrastructure [including compilers, runtimes, libraries, frameworks, profilers, debuggers, etc.] will continue to improve,” Sukumar said. Today’s opportunity may lie in reducing manual work across model conversion, toolchain configuration, hardware bring-up, debugging, optimization, and validation.

For teams evaluating agentic AI as an application layer, the practical milestone is not a tool that produces the most code. It is a workflow that can take an edge deployment objective, operate across the engineering toolchain, and return a result with enough traceability for engineers to determine that it meets the system requirements. As agents move deeper into that process, accurate hardware context, performance targets, and human verification become the deciding factors.