An edge vision agent that runs flawlessly on the engineer’s bench and then breaks the moment it lands on a different board is not a hardware problem. It is a portability problem, and it is usually self-inflicted. The config was baked into the binary, the model weights were hard-coded to a path, the CUDA version was assumed present, and the process kept state in memory that vanished on the first crash. None of these decisions felt wrong at the time. Each one quietly welded the agent to a single deployment context. The 12-factor methodology was written for cloud-hosted web services, not for camera-fed inference on a Jetson module bolted to a factory wall. But the core discipline — separate the deployment concerns from the application, and the application becomes portable — maps onto edge computer vision more directly than most teams expect. The divergence point is exactly the one the original manifesto names: when config, dependencies, and state are entangled with the code, the same artifact cannot move. For an edge CV fleet, that entanglement is what forces a per-site or per-board re-tune, and per-site re-tuning is what stops a fleet from scaling. What does 12-factor discipline actually mean for an edge vision agent? The original twelve factors cover the full lifecycle of a deployable service: codebase, dependencies, config, backing services, build/release/run separation, stateless processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes. Not all of them carry equal weight at the edge. Port binding and concurrency, which dominate web-service design, matter far less on a device processing a single camera stream. The factors that decide whether a vision agent is portable are a smaller set: config, dependencies, stateless processes, and disposability. Config is the one that bites first. A portable agent reads its runtime parameters — camera resolution, model path, confidence threshold, target accelerator, cloud-fallback endpoint — from the environment, not from constants compiled into the binary. When those values live outside the code, deploying to a new site is a config change rather than a rebuild. When they live inside it, every site is a fork. This is the mechanism behind the ROI: externalising config turns per-site redeployment from a bespoke engineering effort into an edit of an environment file (observed pattern across our edge engagements; not a benchmarked figure, and the size of the saving depends on how many sites the fleet spans). Dependencies are the second. A 12-factor agent declares its dependencies explicitly and isolates them — it never relies on a system-wide package happening to be present on the target. On the edge this means pinning the inference runtime, the OpenCV build, the accelerator drivers, and packaging them so the same container or image lands identically on every board. A Jetson image that assumes the host already has the right JetPack and TensorRT versions is not portable; one that carries and declares those dependencies is. We treat this as the difference between an agent that redeploys and an agent that reinstalls. How do the factors map onto Jetson, Coral, and Intel NCS? The hard part of edge CV is that the accelerators are genuinely different. An NVIDIA Jetson runs CUDA and TensorRT. A Google Coral Edge TPU runs a quantised TensorFlow Lite model through its own delegate. An Intel Neural Compute Stick (now folded into the OpenVINO line) runs through the Myriad VPU path. These are not interchangeable runtimes, and no amount of config externalisation makes a single TensorRT engine file run on a Coral. That is the boundary condition, and it is worth stating plainly before the mapping. What 12-factor discipline buys you is that everything around the accelerator-specific model stays constant. The frame ingestion, preprocessing, post-processing, tracking logic, and the decision about where to send results are identical across targets. Only the model-execution stage is swapped, and it is swapped by config — the agent selects the TensorRT engine, the TFLite Edge TPU model, or the OpenVINO IR at runtime based on a declared target variable. The following table shows which factors carry the portability weight and which are largely inert at the edge. Which 12 factors matter most for edge CV portability? Factor Portability weight for edge CV Why Config (externalised) Critical Per-site and per-board parameters must live outside the binary or every deployment is a fork Dependencies (declared, isolated) Critical Runtime, drivers, and OpenCV build must ship with the agent, not be assumed present Stateless processes High State kept in memory is lost on crash and blocks horizontal scaling of inference workers Disposability (fast start/stop) High Fast, clean restarts shorten crash recovery on unattended devices Build/release/run separation Medium Keeps the accelerator-specific build reproducible per target Dev/prod parity Medium The bench and the field should run the same image, or bench success means nothing Logs as event streams Medium Unattended edge devices need logs shipped out, not written to a disk that fills Port binding, concurrency Low A single-camera device rarely needs the web-service concurrency model Backing services, admin processes Low Present but rarely the portability bottleneck for a self-contained agent The pattern is consistent: the factors that decouple the agent from a specific machine are the ones that make it portable, and the factors that were about scaling a stateless web tier matter much less when the workload is one camera and one accelerator. How does externalised config move an agent across hardware without a rewrite? Concretely, a well-factored edge vision agent starts by reading a target descriptor — say CV_TARGET=jetson-orin-nano or CV_TARGET=coral-dev-board — and uses it to resolve which model artifact to load and which execution backend to initialise. The application code that runs the perception loop never branches on hardware; the branch happens once, at startup, in a small runtime-selection layer. Everything downstream operates on the same tensor shapes and the same detection format regardless of which accelerator produced them. This is why the same architecture survives multiple edge contexts. A team that entangles the accelerator choice through the whole codebase ends up with hardware-specific code branches scattered across the perception logic, and each new board multiplies the maintenance surface. A team that isolates the branch reduces the fleet to one codebase with N declared targets. The reduction in hardware-specific branches to maintain is the durable engineering win — faster time-to-deploy on a new target is the visible symptom of it. The trade-offs involved in picking the target in the first place are exactly the ones a computer vision consultant scopes when weighing edge deployment options: latency, accuracy, and power do not move together across Jetson, Coral, and VPU paths. Statelessness reinforces the same portability. If the agent holds no session state in process memory — if tracking history, calibration, and counters are either externalised or reconstructable — then a crashed process restarts clean and a second worker can be spun up beside it. On an unattended device in the field, disposability is not a nicety; it is the difference between a watchdog restart that recovers in seconds and a device that needs a truck roll. Where does the 12-factor model break down for edge CV? Honesty about the boundary matters more than the mapping. Three places the model does not fit cleanly: Local model weights are not config. The original manifesto treats config as small, environment-specific values. A quantised detection model is neither small nor environment-agnostic — it is a large binary artifact tied to a specific accelerator’s numerical format. You externalise which model to load, but the model itself is part of the release, not the config. Treating model weights as a backing service you fetch at runtime is a defensible pattern, but it introduces a network dependency that a truly offline edge device may not tolerate. Hardware acceleration resists dev/prod parity. The 12-factor ideal is that development and production run the same stack. A developer on an x86 workstation with a discrete GPU is not running the Coral Edge TPU delegate or the Jetson TensorRT path. You can narrow the gap with emulation and target-matched CI, but you cannot fully close it — the numerical behaviour of a model quantised for an Edge TPU differs from the same model in float on a workstation, which connects directly to the precision trade-offs covered in our discussion of 4-bit floating point and when to use it for edge inference. Disposability has a warm-up cost. Fast start/stop is a 12-factor virtue, but an accelerator that must load and optimise an engine on startup — TensorRT building or deserialising an engine, for instance — pays a real warm-up penalty. Genuine disposability at the edge often means keeping a serialised, pre-optimised engine on disk so restart skips the build step, which is itself a build/release discipline the manifesto would endorse. These are not reasons to abandon the discipline. They are the constraints that tell you which factors to apply strictly and which to adapt. How does 12-factor discipline connect to the latency, accuracy, and power trade-offs of the edge? Portability and the edge trade-off triangle are not the same axis, but they interact. A portable agent lets you move between hardware targets cheaply; the latency, accuracy, and power profile of each target is a separate decision the architecture then exposes. The value of getting portability right is that the trade-off decision becomes reversible. If a Coral deployment turns out to be too accuracy-limited for a given site, a well-factored fleet lets you redeploy that site to a Jetson target by changing config and shipping a different model artifact — not by rewriting the agent. Where a team has welded the trade-off into the code, that decision is effectively frozen after the first deployment. The relationship between the accelerator choice and its measured latency and power draw is precisely what our computer vision engineering practice helps teams reason about before they commit a fleet. What does a 12-factor edge vision agent look like in a hybrid or cloud-fallback architecture? The cloud-fallback case is where the discipline pays its clearest dividend. A hybrid agent runs inference locally under normal conditions and routes to a cloud endpoint when the local path is unavailable, overloaded, or facing an input the edge model handles poorly. That fallback endpoint is a backing service in 12-factor terms — attached by config, swappable without code change. Because the agent is stateless, either path produces the same detection format, and the decision layer downstream does not care which one served the frame. Because dependencies are declared and isolated, the same agent image runs whether it is doing all its work locally or delegating some of it upward. The failure mode to avoid is a fallback path hard-coded to a specific cloud region or model version. The moment that endpoint moves, a non-portable agent needs a rebuild and a fleet-wide push. A 12-factor agent needs an environment-variable change. That is the whole thesis in one sentence: the discipline is not about the twelve factors as a checklist, it is about which deployment concerns you refuse to compile into the code. FAQ What matters most about 12 factor agents in practice? The 12-factor methodology separates an application’s deployment concerns — config, dependencies, and state — from its code, so the same artifact can run in any environment. In practice for an edge vision agent it means reading runtime parameters from the environment, declaring and isolating dependencies, and keeping processes stateless and disposable, so the agent moves across contexts without a rebuild. How do the 12 factors map onto an edge computer vision deployment specifically? The frame ingestion, preprocessing, post-processing, and result routing stay constant; only the accelerator-specific model-execution stage is swapped, and it is swapped by config. Factors that decouple the agent from a specific machine — externalised config, declared dependencies, statelessness, disposability — carry the portability weight, while web-service factors like port binding and concurrency matter far less on a single-camera device. Which factors matter most for portability across Jetson, Coral, and Intel NCS targets? Config and dependencies are critical; statelessness and disposability are high-weight. Externalised config lets the agent select a TensorRT engine, a TFLite Edge TPU model, or an OpenVINO IR at runtime, and declared dependencies ensure the runtime and drivers ship with the agent rather than being assumed present on the board. How does externalising config let the same vision agent redeploy across different edge hardware without a rewrite? The agent reads a target descriptor at startup and resolves which model artifact and execution backend to load in a small runtime-selection layer; the perception loop never branches on hardware. This reduces the fleet to one codebase with N declared targets instead of a fork per board, turning per-site redeployment into a config change. Where does the 12-factor model break down for edge CV? Three places: local model weights are large accelerator-specific binaries, not config, so they belong to the release; hardware acceleration resists dev/prod parity because a workstation GPU does not reproduce an Edge TPU’s quantised numerics; and disposability carries a warm-up cost when an engine must be built or deserialised on startup, mitigated by keeping a pre-optimised engine on disk. How does 12-factor discipline connect to the latency, accuracy, and power trade-offs of edge deployment? Portability makes the trade-off decision reversible. A well-factored fleet lets you move a site from Coral to Jetson by changing config and shipping a different model artifact rather than rewriting the agent, so the latency/accuracy/power profile of each target stays a separate, changeable decision instead of a frozen one. What does a 12-factor-conformant edge vision agent look like in a hybrid or cloud-fallback architecture? The cloud endpoint is a backing service attached by config and swappable without code change. Because the agent is stateless, local and cloud paths produce the same detection format, and because dependencies are isolated the same image runs whether it works locally or delegates upward — a moved endpoint is an environment-variable change, not a rebuild. Twelve-factor conformance is best read as a portability dimension of production CV readiness: it is the axis that determines whether a vision agent can move across hardware targets without a rewrite, and it is worth assessing before a fleet rollout rather than after the second board forces the question.
