Can agents help move a small ML pipeline closer to the hardware?
An internal prototype for testing whether agents could help take small Python ML pipelines towards constrained edge targets.
Why I built it
A few months after I joined Loka, I started an internal initiative to explore the applications of AI in the aerospace industry. After some discussions with the engineering team and some sales representatives, we defined three sub-domains to tackle: remote sensing, satellite telemetry and edge computing. I personally started with edge computing.
I wanted to test a fairly practical question: could an agent help move a small Python machine-learning pipeline towards an edge target without pretending that the jump from notebook to hardware is automatic?
The interesting bit was not getting an agent to write a convincing answer in a chat window. It was seeing whether an interface could hold the constraints, intermediate steps and evidence around the work: source code, a target profile, generated output, simulation and a report.
What I tested
Space Edge accepted a small Python pipeline and a target profile. The prototype used two deliberately different profiles: a constrained Cortex-M4 and a Jetson Nano, where the available compute and the practical output are not the same problem.
The pipeline moved through a fixed sequence:
- inspect the supplied code;
- select the hardware profile;
- generate target-oriented output;
- run a simulation and collect benchmark information;
- assemble the generated code, logs and report as one job.
Some steps were deterministic. Model calls were useful at the parts where code or an explanation had to be produced, and where the resulting artefacts needed to be brought back into a readable whole. That division mattered: the agent was part of a constrained pipeline, not an invitation to execute whatever it felt like suggesting.
The interface made the process inspectable. It showed the input and target selection beside build progress, a code comparison, benchmark output and the final report. I wanted the work to be reviewable rather than hidden behind a successful-looking completion message.
A prototype, not a deployment claim
This was an internal experiment, not a device deployment system. The targets were simulated, not a substitute for testing on real hardware, and the generated output was not presented as certified or production-ready.
That limit was useful. It kept the prototype focused on the question it was meant to answer: where do agents reduce the tedious translation work, and where does an engineer still need to inspect assumptions, generated code and measured behaviour?
What I learned
The useful interface is around the agent
The chat is the least interesting part once a task has real constraints. Target details, source material, intermediate artefacts and a visible trail of what happened are what make the result possible to review.
Constraints are part of the prompt
A hardware target is not a label added at the end of a generation step. Memory, runtime, tooling and the way a result will be checked need to shape the process from the start.
A benchmark is evidence, not a verdict
The simulated results were useful for comparing paths through the prototype. They were not a replacement for real-device testing, and treating them as one would have made the experiment say more than it could.