--- title: "Who owns what an agent factory learns" url: "https://demertis.com/blog/who-owns-what-an-agent-factory-learns" description: "The valuable part of an agent factory is not the model but what it learns about your firm. Before choosing a vendor, check what stays yours when you leave." --- # Who owns what an agent factory learns November 4, 2026·5 min read·Editorial team Cyanotype print of a wooden card-catalogue cabinet with one drawer of blank index cards pulled open, an open padlock with its key on the hasp, and an idle robotic arm beside it The most valuable part of an agent factory is not the model it calls but what it learns about how your firm works. Instructions corrected for months, the record of every run, the evaluations that say what good looks like, the memory of what worked and what did not. If all of that sits with a vendor, in the vendor’s format and on the vendor’s terms, you do not have a factory. You rent one, together with your own know-how. In [the first post of this series](https://demertis.com/blog/agent-factories-will-not-stay-in-software) we argued that agent factories will spread from software into finance, purchasing and marketing. The question that follows is less about which model is best and more about what remains yours when you change suppliers. ## Why the question appears at all While agents live on individual laptops, ownership looks harmless. In practice it looks like this. Each person installs a different tool and gives it broad access to mail, files and repositories. Instructions and connected tools are written down nowhere. Conversations with agents, the most precise record of how a team actually works, disappear when the window closes. Nobody can tell whether the work is improving, because nothing was kept to measure. A factory fixes that. It gathers agent work into one loop, with one set of permissions, with metrics and memory. That is exactly why the place where the loop runs, and who owns it, becomes a board decision rather than a tool choice made by one team. For a programme like ours the stakes are higher still. A firm that one day lets a loop operate, repair and improve parts of itself is building an operating memory. If that memory is held by someone else, so is the ability to understand, audit and stop the loop. ## What you actually own An agent factory is not one program. It is a set of layers, and each can belong to you or to the supplier. Layer What it is What you lose if the vendor holds it Minimum worth keeping yourself Factory definition stages, agents, triggers and rules for moving work on you cannot rebuild the loop elsewhere or undo a bad change the definition as code in your repository, with history Instructions how an agent reviews, describes and checks work in your firm months of corrections by your own people plain files readable without the vendor’s tool Tools and permissions what an agent can reach and change control over who sees your data one inventory of permissions that you manage Run history and memory inputs, decisions and results of every task the most accurate process record the firm ever had storage in your own cloud account or premises Evaluations how quality, cost and throughput are judged the ability to compare suppliers on your own work your own fixed set of test tasks and results Interrupt the means to pause or stop the loop the ability to stop it without the vendor’s cooperation a stop that works from outside the vendor’s platform Model and runtime which model does the work, and where freedom to switch when price or quality moves a model swap that does not require rewriting instructions Two layers in that table come from our own work rather than from the usual vendor checklist. Evaluations are the factory’s definition of better, and as we argued in [a yardstick the system cannot edit](https://demertis.com/blog/a-yardstick-the-system-cannot-edit), whoever controls that definition controls where the loop drifts. The interrupt is the subject of [an off switch that survives the system](https://demertis.com/blog/an-off-switch-that-survives-the-system): a stop that depends on the vendor’s console is a stop the vendor owns. Note where the model sits. Models get cheaper and change every few months. Instructions, memory and evaluations grow in value with every week the factory runs. If you could carry only one layer with you, carry those. ## Three routes and their price There are three ways to get a factory today. None is free. **A ready-made factory as a service.** You buy a “virtual team member” that does the work. It is the fastest start. The price is that the definition of the work, the memory and the evaluations stay with the supplier, and customisation ends where the settings panel ends. **Your own factory from scratch.** The team glues together scripts, queues and model calls. The first agent runs within a week. The price is that six months later your best engineers maintain plumbing instead of the product, and every new stage of the loop is a new project. **Open infrastructure that you run.** A supplier provides the control layer: work queue, dashboard, metrics, a way to launch agents. The definition, instructions, memory and data stay in your repository and your cloud. You can use several models, including open ones, and compare them on your own tasks. The price is that someone in the firm has to understand that infrastructure and answer for it. ## Where sovereignty becomes an expensive hobby Sovereignty can be overdone. A firm of eighty people does not need its own GPU servers to own its factory. Buying hardware “so the data never leaves” when nobody can maintain it ends with agents running on laptops again, only at greater cost. For most firms it is enough that the definition, instructions, memory and evaluations live with them, that the contract with the model provider excludes training on their data and retaining their prompts, and that the architecture allows a switch to another model within a week. The second trap is treating open models as a goal. An open model can be cheaper and can run on your own hardware, but on some tasks it will be weaker. A factory earns its keep when each stage can use the model that suits it: a cheap one for sorting, a stronger one for writing descriptions, and for review whichever performs best on your own test set. ## Measure sovereignty by the cost of leaving Sovereignty is not measured by a sentence in a security policy. It is measured by what it costs to walk away. Vanity metric Outcome metric “our supplier is fully compliant” working days needed to move the factory to another model provider number of models available in the dashboard share of tasks that run on models you could host yourself “everything is in the cloud” whether last quarter’s run history can be read without the supplier’s account “we have a kill switch” whether the loop can be stopped while the supplier’s service is down ## A test you can run this week Ask your team where the instructions they give agents are stored, and where their conversations with those agents end up. Then ask a second question: if we had to change model provider tomorrow, what would we have to write again? If the answer is “everything”, your factory, however young, already belongs to someone else. That leaves a choice. You can build fast on someone else’s infrastructure and accept that the knowledge of how your firm works will live there. Or you can build a little slower and keep that knowledge, and the switch that stops the loop, on your side. Both have a price. The worse outcome is making neither choice on purpose. - agent factories - sovereignty - vendor lock-in - operating memory ## Keep reading - [How to build an agent factory, stage by stage](https://demertis.com/blog/how-to-build-an-agent-factory-stage-by-stage) - [Agent factories will not stay in software](https://demertis.com/blog/agent-factories-will-not-stay-in-software)