Electronicseng General: Agentic AI Edge Software Engineering Workflow Guide

For the Electronicseng General audience, the useful test for agentic AI is not whether an agent can write code, but whether it can carry an edge software change through the same engineering checks a human would perform.

An edge model cannot ship from generated source text alone. It must be compressed or quantized for the available memory, compiled for the chosen processor, integrated with a runtime, and validated for latency, power consumption, accuracy, and behavior around neighboring embedded components. Agentic AI can connect much of that sequence, letting a development agent work with compilers, test frameworks, profilers, debuggers, documentation, and deployment tools rather than only producing code.

That coordination can shorten a cycle that once depended on repeated manual handoffs. Embedded hardware, however, creates a demanding boundary. As agents move deeper into deployment, optimization, and hardware integration, they need reliable target-system context before their results can be checked and trusted.

A coordinated agentic workflow can automate the edge AI development stack, helping teams build, deploy, and manage models at the edge (Source: Adobe Stock)

From disconnected stops to a connected workflow

In many embedded projects, a single change passes through disconnected stops: requirements review, source or model editing, build-system setup, compiler invocation, test creation, documentation search, log analysis, and defect localization. Edge AI layers additional stops such as quantization, graph optimization, runtime selection, and deployment on the board.

An agent can reduce those handoffs when it treats an engineering objective as a sequence of tool calls. It chooses actions, invokes the available toolchain, inspects results, and continues until the output can be checked. The practical gain often comes from linking existing steps and existing engineering information rather than inventing new knowledge.

Embedded.com spoke with Vinesh Sukumar, who leads the AI and machine-learning product management team at Qualcomm Technologies Inc., and he described today’s edge AI development sequence as still being step-based, moving through quantization, compilation, and runtime selection.

When developers want to place generative AI models on Qualcomm platforms, Qualcomm AI Hub gives them utilities for taking models from open-source repositories, getting them ready for supported devices, and measuring behavior on target hardware. AI Runtime is another Qualcomm offering: optimized libraries and operators run models across its compute engines. According to Sukumar, an agentic layer is being pursued to automate more of quantization, compilation, runtime selection, and deployment.

Qualcomm AI Hub helps prepare, optimize, and evaluate models on supported hardware (Source: Qualcomm Technologies Inc.)

A firmware example: faster build, unchanged review duty

A goal such as precompiling a model for a target device, tuning it for performance, and coordinating the necessary software tools may be expressible as an agentic workflow. Embedded.com spoke with Rohini Ramegowda, a firmware engineer at Torus Inc. working on safety-critical embedded and real-time systems, who described a narrower workflow she already uses in firmware development.

Her agent reads prepared requirements, calls a MathWorks MATLAB MCP server to construct a MATLAB and Simulink model, creates unit tests from an existing template, and runs the simulation; Ramegowda then reviews the model manually against the requirements.

Before this setup, she selected suitable Simulink blocks manually, consulted MathWorks documentation when necessary, and inserted them by hand. “That used to take weeks,” she said. “Now it generates it in hours. But the review part remains the same.”

Cross-artifact diagnosis can also improve. After a device reported many faults, Ramegowda gave an agent a configuration binary, the generating script, and the codebase; the agent linked binary fields back to firmware structures and found a mismatch within minutes.

Hardware limits keep the agent honest

Edge devices still constrain every decision: memory, storage, bandwidth, compute capability, and power consumption are finite. The processor family also determines which numerical formats and model operations can run efficiently, so a model that works on one system may need different quantization, compilation, and runtime choices on another.

Sukumar explained that for large generative models, moving from a 16-bit model to INT8, INT4, or even lower precision can shrink memory and storage needs. Equally important is hardware support: dedicated neural processing units (NPUs), memory architectures, and power-management methods determine whether the workload can meet performance goals.

When a deployment or porting task is given to an agentic workflow, hardware facts become part of the plan. Sukumar said an agent would first need target system-on-chip memory, storage, and bandwidth, then retrieve the related configuration and generate binaries tuned to that hardware.

Porting is not just reusing the same model binary on another processor; quantization, graph partitioning, compilation, and runtime settings all have to fit the new performance limits. Ramegowda pointed out driver, hardware abstraction layer, linker script, and memory configuration differences across controllers. “I wouldn’t think it would be completely autonomous,” she said.

Ramegowda’s work with STMicroelectronics’ STM32N6 microcontroller illustrates the boundary. She used an agent to bring up the board, configure an embedded Rust toolchain, and debug boot and flashing issues; reaching a flashed “Hello World” still took roughly a week with adjustments. The key question of how NPU inference should share the processor with a deterministic control loop stayed a manual architecture decision. When common interfaces already exist, application-level software is easier to move, while adapting the hardware abstraction layer requires more knowledge of the specific controller.

Verification shifts the bottleneck to review

Once agents produce more source files, models, tests, and configuration files, the engineer’s job becomes proving that the implementation behaves correctly inside the whole embedded system. This can increase review volume rather than reduce it.

For Ramegowda, the effect is visible in safety-critical firmware. Handwritten code already carries the assumptions and architectural choices in her mind. With AI-generated code, review must rebuild those assumptions. “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.” The review can include memory-region checks and placement of functionality into deterministic or nondeterministic layers.

Functional behavior is one dimension; process and coding-rule compliance is another. Ramegowda said she verifies whether generated code follows standards such as MISRA and whether the required engineering process was followed.

In certain cases, reviewing and fixing agent output may take longer than writing code manually. Static analysis, unit tests, simulation, processor-in-the-loop, and hardware-in-the-loop give more evidence, but no single test proves generated embedded software safe under all operating conditions.

Edge AI deployment has the same verification gap. A model that compiles and runs on the target does not necessarily use 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 result reflects attainable hardware performance.

Checklist: what an edge AI agent needs before it acts

• Target platform constraints: memory, storage, bandwidth, compute capability, and power limits.
• Existing engineering artifacts: requirements, source code, model files, build configuration, tests, logs, and documentation.
• Tool access: compilers, profilers, debuggers, logging systems, and validation harnesses.
• Expected performance range: memory and energy consumption on the target platform.
• Review rules: functional checks, safety-critical process requirements, coding standards such as MISRA, and deterministic-layer placement.

Common misconceptions

• More generation means less engineering. Agents can accelerate manual steps, but they also increase the amount of output that must be understood and verified.
• A running model means an efficient model. Successful compilation and execution do not prove that the hardware is being used well.
• Porting is only re-running a binary. Quantization, graph partitioning, compilation, and runtime configuration may all need to change.
• Hardware abstraction can be automated at every layer. Application-level software may move more easily when common interfaces exist, while hardware-specific architecture still requires engineer decisions.

FAQ: General engineering questions on agentic edge workflows

Can agentic AI make embedded development fully autonomous?

Not with the present set of tools. Sukumar expects human involvement to decrease as tools mature: “I don’t think it’s going to be completely zero,” he said.

What infrastructure supports an agentic workflow?

As the foundation for an agentic workflow, Sukumar points to compilers, profilers, debuggers, logging systems, documentation, and expected performance data. If a model fails to compile, simply reporting the failure is not enough; the agent needs more log history and diagnostic information to identify the cause, locate documentation, and determine the next action. In Sukumar’s summary, the infrastructure will keep advancing: “I’m pretty confident that the infrastructure [including compilers, runtimes, libraries, frameworks, profilers, debuggers, etc.] will continue to improve,” he said.

What can engineers delegate today?

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.

How should performance be judged?

Implementation time can be shortened by agentic AI, and edge AI deployment accelerates if engineers can also verify generated output efficiently. Developers need a target-platform reference range, then compare memory and energy consumption against it. If the result is outside the range, the deployment or configuration needs work.

Closing note for edge software teams

The most useful milestone is not an agent that produces more code; it is one that can take an edge deployment objective, move across the engineering toolchain, and return enough traceability for engineers to confirm system requirements. The practical path is to automate connected steps, provide accurate hardware context, and keep human verification where hardware behavior, safety, and architecture are concerned.