How Open Is Your Software Factory?

Your factory gets smarter. Can you take that intelligence with you?

Before you commit your company’s work to a software factory, ask two questions: can you bring your context in, and can you take what it learns out? The first question gets plenty of attention. Connect your repositories. Add your documentation. Configure your tools. Tell the agents how your team works.

The second becomes more consequential with every run. Your engineers explain architectural decisions. Reviewers correct recurring mistakes. Incidents reveal constraints that were never written down. Evaluations establish what acceptable work looks like. Over time, the factory accumulates an increasingly valuable understanding of your business.

If you change the model, coding agent, harness, or factory itself, how much of that understanding comes with you? A factory that accepts your knowledge but traps what you learn is a one-way door.

The valuable output is more than code

The historical factory analogy helps explain the stakes. Buying a manufactured product does not automatically give you the knowledge required to produce it. You acquire the output, while the manufacturer retains the process knowledge: how to handle exceptions, detect defects, and improve the next production run. That is often a sensible bargain. Most companies should buy commodity components. But when the production process contains the knowledge that differentiates your business, deciding where that knowledge accumulates becomes a strategic choice.

In an AI-powered software factory, your people help create that knowledge. They supply context, demonstrate judgment, and explain why a plausible answer is wrong. Your operations reveal whether the resulting software actually works. The factory produces code. It also produces a better understanding of how your company builds software.

You can own every line of generated code and still depend on one platform for the understanding that produced it. Losing that understanding means paying to reconstruct decisions, rediscover exceptions, and explain the same lessons again. The code can leave while the know-how stays behind.

Open components are a starting point

There are several useful ways to make a factory open. Support multiple models. Connect external coding agents. Run in an environment the customer controls. Expose interfaces for existing tools. Each creates valuable freedom. None, by itself, tells you whether the knowledge accumulated through production can move elsewhere.

The next question concerns the knowledge accumulated inside that infrastructure: what can you inspect, extract, and put back to work independently? Keeping information within your environment addresses one concern. Choosing between models addresses another. Carrying your maintained skills, architectural decisions, evaluation cases, and learned constraints into a different production system addresses a further dependency.

An open software factory should make that possible. Its context and learning should remain understandable, governable, and reusable under your control, with a life beyond any one component or supplier.

Bring your context

Your organization already has knowledge worth using. It lives in repositories, internal documentation, tickets, architectural decisions, business systems, and people’s experience. Bringing context means connecting that understanding to the work without requiring the company to recreate itself inside a new product.

A connector can retrieve a document. Useful context also tells the agent whether that document is current, which agreement takes precedence, and where an exception applies. Sources, permissions, and relationships matter as much as the text.

The factory should accommodate your existing skills and instructions, your model gateway, your evaluations, your observability, and your approval workflows. Where those systems already work, they are part of the production capability you bring. You should also be able to bring your own loop. Start with a supplied workflow, enhance it, or replace it with a hardened sequence that reflects your requirements. The company needs control over how context is gathered, actions are checked, and feedback is incorporated.

Take your learning forward

Consider a coding agent that bypasses an internal service and writes directly to a database. The implementation appears reasonable, but misses the authorization and audit behavior provided by the service. A reviewer catches it and explains why the service exists.

The immediate fix is a better pull request. The durable improvement could be several artifacts:

• An architectural decision explaining the boundary and its rationale.
• A skill describing how to make this class of change.
• An evaluation case checking whether an agent respects the boundary.
• An automated check that catches violations before review.

Those artifacts turn one correction into knowledge that can guide future work. They should remain accessible when another developer, agent, or workflow takes over. An exported transcript is evidence of the conversation. It does not necessarily tell you which lesson was accepted, where it applies, or how to verify that another system uses it correctly.

Useful extraction preserves meaning. A lesson needs its source, scope, review status, and supporting evidence. A skill needs its dependencies. An evaluation needs enough of its environment to run again. This is also why learning requires judgment. A workaround should not silently become policy. A temporary exception should not become a universal rule. Someone must decide what deserves to be retained and test whether the proposed improvement helps.

A practical starting point is to turn recurring problems in development work into improvements to skills and workflows. Those improvements should remain assets you can use throughout your engineering system.

Make openness observable

“How open is your factory?” should be answerable through things a team can demonstrate.

Transparency: Can you inspect the context that guided a run, the sources it used, and the changes made after feedback? Can an engineer understand and challenge the rules governing production? This concerns observable inputs, artifacts, and actions; it does not require access to every internal step of a model’s reasoning.

Reproducibility: Can you reconstruct the relevant instructions, versions, tool responses, and conditions behind an outcome? Probabilistic systems may produce different results, but retained context and local test environments make replay and comparison meaningful.

Interoperability: Can your knowledge remain useful across models, coding agents, and harnesses? Model independence is one layer. The application, execution loop, memory system, and tools can each introduce dependencies. Adapters and retesting may be necessary; rebuilding your institutional understanding should not be the price of switching.

Ecosystem reuse: Can you author a skill with one tool, evaluate it with another, and use it across several workflows? Can you keep your existing gateway, connectors, and monitoring? An open factory lets you combine capabilities instead of repeatedly recreating them inside each platform.

Skills, plugins, agent instruction files, and emerging protocols help here. Shared formats alone cannot guarantee equivalent behavior, permissions, or memory semantics. The evidence is whether another system can use the artifacts and pass your checks. An export becomes an exit path when you can put it back to work.

Context becomes something teams can improve together

Making knowledge explicit and reusable has another consequence: it can make the organization more transparent to itself. A service convention previously explained in private conversations becomes guidance product teams can find. A recurring review comment becomes a rule people can discuss. A lesson from an incident can improve both an implementation skill and an automated reviewer.

Context becomes a durable artifact with a collaborative lifecycle. People can propose changes, review the evidence, resolve disagreements, and see which version is authoritative. Other teams can build on the result. That collaboration matters because vendor lock-in is only one way knowledge gets trapped. Departments, repositories, and individual agent memories can become silos too. A company can control its infrastructure while maintaining several incompatible versions of how its business works.

Shared context does not require universal access. Sensitive information still needs appropriate permissions. The aim is to make knowledge available to the people and tools authorized to use it, wherever their work happens.

Start with one workflow—and rehearse the move

An open software factory does not require building an entire platform before getting value. Choose one bounded workflow where the team repeatedly explains the same context or corrects the same mistakes. Connect its authoritative sources. Capture a few useful lessons. Turn them into maintained skills and evaluation cases, with someone responsible for their quality.

Then try using those artifacts elsewhere. Give the workflow to another coding agent. Run its evaluations through a different harness. Ask another team to apply the skill. Notice what survives, what requires adaptation, and what was silently dependent on the original environment. That exercise makes openness concrete. It also improves the documentation and exposes assumptions long before you need to change suppliers.

Local, on-premises, VPC, and hosted deployments can all play a part. Choose them according to the workload and its requirements. Deployment location alone cannot tell you whether your accumulated knowledge is inspectable or reusable.

Ownership also involves maintenance. Context becomes stale, evaluations need attention, and integrations cost effort. For commodity work, a complete managed product may be the right answer. Focus your investment on the knowledge that differentiates your business and would be expensive to reconstruct.

Keep the door open

A factory that improves with use is valuable. That value should strengthen your organization’s capabilities while preserving its choices. Buy excellent components. Adopt standard skills. Use managed services where they help. Keep control of the context, workflows, evaluations, and learning that make the production system yours.

The test of an open software factory is whether you can bring your understanding into it, see how that understanding changes, and take the resulting knowledge forward. Your factory should leave you with more knowledge—and more options—than you brought in.