Ship an edge computer vision “agent” as one binary — model weights, config, runtime, control loop, and local state all fused together — and it runs fine until the first firmware update. Then the monolith you flashed to the device becomes the thing you have to re-architect. Swapping a hardware target, rolling back a model version, or reasoning about how the agent recovers after a failure in the field all turn into surgery on a fused artifact instead of a bounded change. The fix is not a new framework. It is a discipline borrowed from the twelve-factor methodology that web engineers have used for a decade: separate config from code, treat models as versioned backing services, keep the agent process stateless wherever it can be, and make its behaviour reproducible across deployment contexts. On edge CV specifically, that discipline is what keeps a latency-tuned deployment from silently regressing when the model or runtime changes underneath it. What does “12-factor agents” mean when the agent is an edge CV system? The original twelve-factor manifesto was written for cloud-hosted web services. An edge CV agent is a different animal — it lives on constrained hardware, often disconnected, running a perception loop against a camera feed under a hard latency budget. But most of the factors translate cleanly, and the ones that translate are exactly the ones that make edge deployment survivable. The core reframe is this: an “agent” here is not the model. It is the process that owns the perception loop — it reads frames, calls the model, applies decision logic, and emits actions or events. The model is a backing service the agent depends on, not part of the agent itself. Once you hold that distinction, the factors stop being abstract cloud advice and become concrete separation lines you draw through your firmware image. A helpful way in is to see what each factor maps to on the edge. Not all twelve carry equal weight here — some are load-bearing for edge CV, a few are near-irrelevant, and one or two need reinterpretation. What does each of the 12 factors map to for an edge CV agent? Factor (original) Edge CV interpretation Weight on the edge Codebase One agent codebase, many device deployments from it High Dependencies Runtime (TensorRT, ONNX Runtime, OpenVINO) declared, not assumed present on device High Config Camera params, thresholds, model URI, target device — all injected, never baked in Critical Backing services Model artifact treated as a swappable, versioned resource Critical Build/release/run Build the image, release with a pinned model + config, run without mutating either Critical Processes Agent process stateless; no in-memory state that can’t be rebuilt High Port binding Local IPC / event socket the agent exposes Medium Concurrency Scale the perception loop by process, not by threading everything into one binary Medium Disposability Fast startup + clean shutdown so a crashed agent restarts without corrupting state High Dev/prod parity Same runtime and model format from bench to device High Logs Emit event/telemetry streams; don’t write to a local file the device can’t rotate Medium Admin processes Recalibration, model warmup run as one-off tasks against the same build Medium The three marked critical — config, backing services, and build/release/run — are where the monolith-versus-factored divergence actually shows up. If you get only those three right, most of the field-maintenance pain disappears. Why separating config, model, and state improves reliability across hardware targets Here is the failure the monolith hides. You tune a model on a Jetson Orin, measure a clean latency and accuracy envelope, and flash it. Six months later procurement moves you to a different accelerator, or the vendor ships a runtime update. Because the model, the config, and the control code were compiled into one artifact, you cannot isolate what changed. Every migration becomes a full re-validation, because you have no clean boundary that tells you this part is portable and that part is device-specific. Separation gives you those boundaries. When the model is a versioned backing service — an artifact referenced by URI and pinned by hash — moving to new hardware means recompiling the artifact for that target and re-pointing the agent, not rewriting the agent. When config is injected rather than baked, the same agent binary runs across a fleet of heterogeneous devices with per-device thresholds and camera intrinsics supplied at deploy time. This is the same portability logic we describe in 12-Factor Agents for Edge CV: Portability Principles for Deployable Vision Pipelines, applied one layer down at the artifact boundary. The reliability payoff is measurable in redeployment effort. In our edge CV engagements, teams that factored config and model out of the binary turned hardware-target migrations from a re-architecture into a config-plus-artifact swap (observed pattern across TechnoLynx engagements; not a benchmarked rate — the size of the win scales with how many device SKUs are in the fleet). The monolith’s re-architecture cost is roughly constant per migration; the factored agent’s cost drops toward the marginal cost of recompiling one artifact. State separation closes the loop. If the agent process holds no state it cannot rebuild — no accumulated calibration drift living only in RAM, no unlogged event history — then a crashed agent restarts clean and a device can be re-provisioned without a technician physically present. That is the disposability factor doing real work on hardware you cannot easily reach. How does 12-factor discipline preserve a characterised latency/accuracy envelope? The most under-appreciated benefit is envelope preservation. When you characterise an edge deployment, you produce a contract: at this precision, on this runtime, on this device, the model runs within this latency band and holds this accuracy. That contract is only meaningful if the three variables it depends on — model, runtime, device — are pinned and swappable one at a time. A fused monolith destroys the contract on the first change, because you cannot vary one axis while holding the others fixed. A factored agent preserves it. When the model version changes, you re-run the envelope check against the same pinned runtime and device, and you know the delta you measured is attributable to the model alone. This is the discipline that keeps a latency-tuned deployment from silently regressing — the regression, if it happens, is visible and attributable rather than buried in a rebuild. Runtime choice is part of this. Whether you compile through TensorRT, ONNX Runtime, or OpenVINO changes the numbers, and the build/release/run separation is what lets you treat the runtime as a pinned dimension rather than an ambient assumption. If you are still deciding which runtime and hardware pairing fits your latency budget, DGX Spark Performance for Edge CV: Where It Fits in the Latency/Cost Trade-off walks through how those trade-offs land in practice — and the factorisation discipline here is what lets you re-measure cleanly when that choice changes. A quick diagnostic: is your edge CV agent actually factored? Run this checklist against a deployment before you call it maintainable: Can you change a detection threshold without rebuilding the image? If no, config is not separated. Is the model referenced by a versioned URI + hash, or compiled in? If compiled in, you have no backing-service boundary. Can the same agent binary run on two different device SKUs with only config differences? If no, device-specific logic has leaked into code. If the agent process is killed mid-loop, does it restart to a correct state with no manual intervention? If no, you are carrying unrecoverable in-memory state. Can you roll back to the previous model version as a config change rather than a reflash? If no, rollback is an emergency, not an operation. Does bench and device run the same runtime and model format? If no, your envelope characterisation does not transfer. A “no” on items 1, 2, or 5 is the signal that you have a monolith wearing an agent’s name. Those three are the load-bearing separations. Which factors matter most for edge CV versus cloud-hosted agents? The weighting shifts with the deployment context, and this is where blindly copying cloud twelve-factor advice goes wrong. A cloud agent leans hardest on concurrency, port binding, and horizontal process scaling — it lives in an environment with elastic compute and reliable networking. An edge CV agent inverts that emphasis. On the edge, the load-bearing factors are config separation (you deploy across heterogeneous, physically distributed hardware), backing-service treatment of the model (hardware targets change under you), build/release/run separation (you need reproducibility across contexts you can’t reach), and disposability (a crashed agent on a remote device must self-recover). Concurrency and port binding matter far less — you are usually running one perception loop per device, not scaling out. Logs need reinterpretation: an edge device often can’t rotate a local file or reach a log aggregator continuously, so telemetry becomes an event stream buffered for intermittent connectivity. The reason the emphasis inverts is physical reach. Cloud twelve-factor optimises for elastic scaling in a controlled environment. Edge twelve-factor optimises for maintainability across an uncontrolled, distributed, occasionally-disconnected fleet. Same principles, different centre of gravity. Scoping which factors actually earn their keep for a given deployment is exactly the kind of trade-off analysis a computer vision consultant scoping edge deployment works through before committing to an architecture — and it is a reliability dimension of a broader production CV readiness assessment. FAQ How does 12-factor agents work? Twelve-factor is a set of separation principles: config, dependencies, model artifacts, and state are pulled out of the code so the agent process becomes portable and reproducible. In practice it means the thing you flash to a device is not a fused monolith but a slim agent that reads its config from the environment, references its model as a versioned external artifact, and holds no state it cannot rebuild. The payoff shows up on the first update or hardware migration, when a change that would have been a re-architecture becomes a config or artifact swap. What does each of the 12 factors map to when the agent is an edge-deployed computer vision system? The agent is the perception-loop process, not the model — the model is a backing service it depends on. Config maps to camera params, thresholds, and the model URI injected at deploy; backing services map to the versioned model artifact; build/release/run maps to shipping a pinned model plus config that never mutate at runtime. The mapping table above marks config, backing services, and build/release/run as critical, disposability and dev/prod parity as high, and concurrency/port binding as lower-weight for edge. How does separating config, model artifacts, and state improve reliability across different edge hardware targets? Separation creates clean boundaries between what is portable and what is device-specific. Moving to new hardware means recompiling the model artifact for that target and re-pointing the agent rather than rewriting it, and one agent binary can serve a heterogeneous fleet with per-device config. Stateless processes mean a crashed agent restarts clean and a device can be re-provisioned without an on-site technician. How does 12-factor discipline preserve a characterised latency/accuracy envelope when models or runtimes change? The envelope is a contract that only holds if model, runtime, and device can be pinned and varied one at a time. A factored agent lets you change the model while holding the runtime and device fixed, so any measured delta is attributable to the model alone. A fused monolith destroys that contract on the first change because you cannot isolate which variable moved. Which factors matter most for edge CV agents versus cloud-hosted agents, and why? Edge CV inverts the cloud emphasis: config separation, backing-service model treatment, build/release/run reproducibility, and disposability are load-bearing, while concurrency and port binding matter far less. The reason is physical reach — cloud twelve-factor optimises for elastic scaling in a controlled environment, edge twelve-factor optimises for maintainability across an uncontrolled, distributed, occasionally-disconnected fleet. How do you make an edge CV agent reproducible and rollback-safe without re-architecting on every update? Pin the model as a versioned artifact referenced by URI and hash, inject config rather than baking it in, and keep the process stateless. Rollback then becomes re-pointing config to the previous model version instead of an emergency reflash, and reproducibility follows from build/release/run separation plus dev/prod parity on the runtime and model format. The open question for most teams is not whether to factor an edge CV agent — it is which factors to enforce hard given a specific fleet and latency budget, and which to leave loose. That decision belongs upstream, at the point where you characterise the deployment’s latency and hardware trade-offs; agent-level factorisation is the reliability discipline you apply once those trade-offs are named.
