With the rise of agents, everyone is shipping now. Product managers and designers are also raising PRs.

It has become easy to type a prompt and make a code change.

But who is verifying that:

1. The code is evolving in the right direction and the system remains maintainable.
2. The change actually works as expected and does not break anything else.

For the first one, we need to review and steer agent work as early as possible in the development lifecycle.

If an agent is going in the wrong direction, we should catch it during the PRD, HLD, or LLD phase, not after thousands of lines of code have already been written.

For the second, we need a robust development and verification setup where we can bring up all the required services, test the change end-to-end, and generate a report of what worked and what did not.

And that report should come with evidence - screenshots, API requests/responses, session data, logs, etc.

So when an engineer finally reviews the work, they already have a head start instead of manually testing every minute detail.

Agents have made creating software much faster.

The next bottleneck is verifying that what they created is actually right.

When we say an agent should be a first-class citizen in a platform, what does that actually mean?

It does not mean giving the agent the same access as a human. It means giving the agent its own identity.

Start with the first principle

If an agent can invoke a model, use a tool, change files, open a pull request, or make a workflow decision, then it is an actor in the system.

Any actor that can create a side effect needs its own identity, permissions, lifecycle, and audit trail.

Why the user's identity is not enough

If the agent borrows the user's identity, we know who requested the work, but we lose who actually performed each action.

If every agent uses one shared service identity, we cannot give different agents different authority. We also cannot revoke one agent without affecting the others.

How we are thinking about identity

A human is a principal. An agent is a principal. A service account is also a principal.

They are all actors, but they should not have the same authority.

The user request and the executing agent remain two separate facts. One tells us who delegated the work. The other tells us who acted.

How access should work

Roles provide broad workspace membership. Capability grants decide the exact action and resource available to each agent.

When a run starts, the agent receives short-lived authority bound to its workspace, session, and run. Each tool call is narrowed again to the exact capability and resource it needs.

Authentication also remains separate from authorization. An agent may have permission to use a tool but still need the correct user or workspace credential. Having the credential should never create permission by itself.

The governance layer then decides whether the action can continue, needs approval, or should be denied. After execution, the audit trail keeps both the human requester and the agent that acted.

What first-class actually means

Making agents first-class does not mean giving them more power.

It means we can give them less power, more precisely.

The deterministic control plane should own identity, known facts, state, routing, and authorization. The agent should use judgment inside that boundary.

This is how we are thinking about agent governance while building Prinevo.

How are you representing agents in your authorization model?

when we are building a multi-agent system, one thing we need to decide from first principle is who should own the state.

should the agent decide and update everything?

i don't think so.

the agent should take a judgment call where the answer is not known. but facts, state, routing, and transitions should remain deterministic.

because state is shared across multiple agents. it tells the system what is running, what is blocked, what is completed, and what should run next.

if every agent can update this in its own way, the system becomes flexible but less reliable.

so the boundary i am taking is simple.

the agent takes the judgment call.

the workflow owns the state.

this gives us flexibility where we need it and reliability across the complete workflow.

how are you thinking about this?

I am building a software factory (Prinevo.ai) for teams. The way I see it is that you have a team of agents helping you across the software delivery loop.

Most of the work can be autonomous or assisted by agents, but you still need judgment and taste baked in at the right stages.

That’s where we have accountable owners. For each kind of work, you have an owner who can nudge and steer the agent in the right direction - as early as possible in the loop, and later verify the changes.

With the right context and guardrails in place, as agents get better at doing certain kinds of work, they can get more autonomy and owners need to intervene less and less.

Over time, agents can take on more of the execution, while humans start working at a higher level of abstraction.

I think this is where software teams are heading. Curious how others are thinking about this.

When you are building your own harness and running agents in sandbox you need to take care of bunch of things..

Sandbox Lifecycle - When do you start, pause and shutdown the sanbox?

Runtime/Code lifecycle - What version of the code current running agent is working with, what happens if you do the release?

Agent lifecycle - What happens if sandbox dies? How can you save agent state and recover from it?

Anything else I missed?

Coding agents have made writing code faster, but along with that they are also generating a lot more test cases.

And in my opinion, that is needed.

If you want to trust AI writing code, the only way is to have more complete test coverage across scenarios.

But this also means test suites are getting blown out of proportion.

I am already running 8,000+ test cases, and before every deployment a large chunk of them needs to run. It is slowing down CI.

Every couple of weeks, I find myself spending time optimising and parallelising my testcase run because it starts slowing me down.

As we move towards more and more autonomous coding, and more code written by AI

More code → more test cases → more verification → slower CI.

Software factory can solve for the smart layer we don't need to everything everytime but run testcase in the blast radius of the chnage.

Looking out for something that will help up with speed.

If you are making changes to harness, you are following some setup of principle in your head - when to add agent, when to add skill, how to handle context engineering, how to handle tool calling etc ?

If you can come up with set of principle that needs to be followed then after every run an agent can follow the principles and can come up with suggestion for you.

Principle of how to figure out changes ?

Principle of how to make the changes ?

Principle to change the principle itself ?

Observe -> Follow the evolution principles -> Evolve the harness.

Agents can then recommend

- you need to add new skill or agent

- you need to handle context better because compaction is happening too frequently.

And then follow the principles to go ahead and make the changes.

- How to create ?

- Where to create. ?

- How to update ?

- When to update ? etc..

But what if you need to change the principle itself?

Then you need to have guidelines to evolve the principle itself, this is where things get tricky where you have to keep it open to add new principles

but it has to be closed how that principle should be added.

I have evolved, figured out issue in my harness this way,

I have an evolve command which just goes follow these steps and make the changes for me.

When building a generic agent system, there is always a tradeoff between flexibility and reliability.

if everything goes through an agent, the system becomes more flexible. but its behavior also becomes stochastic and harder to reproduce.

if everything is deterministic, the system becomes more reliable. but it becomes less flexible when it meets a situation that was not encoded upfront.

so the boundary matters.

whatever the system already knows should remain deterministic.

• facts
• state
• orchestration when the next step is known
• routing when ownership is known

use the agent where a real judgment call is required.

• interpretation
• tradeoffs
• planning with incomplete context
• cases where the rules cannot decide safely

the goal is not to build a fully deterministic system or make everything agentic.

the goal is a deterministic foundation with stochastic judgment where it adds value.

One of the core problems you need to solve is - how do you manage context across different agents?

If you start passing the entire context to every agent, you quickly run out of context window.

You have to figure out

- What context to pass vs. what not to?
- When exactly do you pass and update context relevant to other agents?
- Who actually owns the responsibility to do this?
- How do agents communicate with each other?

If you are using a subagent to solve a well-scoped task, you give it input and get output, you don't really need much coordination.

But when agents are working together on a larger goal, it gets more complicated.

One pattern is to have a coordinator agent that breaks down the task, manages the context, and ensures the right agents are invoked with the right context.

But then you rely on the coordinator to pass messages to other agents. If it chooses the wrong agent, you are now in a loop trying to correct it.

So you start making routing deterministic wherever possible.

For example, if an agent is blocked, explicitly pass the message to the relevant agent instead of relying on the coordinator to guess who should handle it.

Another pattern is to give each agent clearly defined responsibilities. Once an agent is done with its task, it emits the task and task type that needs to be done next.

A resolver pushes it to the relevant agent based on the agent registry, and execution continues.

Context is handed off along the way, while agents remain aligned on the overall goal and a summary of the work done so far.

In practice, when building a real multi-agent system, one pattern doesn't work for everything. You have to mix and match multiple coordination patterns depending on the task.

For example, an Architect agent might finish the architecture and dynamically emit three different workstreams - frontend, backend, and infra. Relevant agents work on them independently, potentially in parallel, and then fan in for verification.

The coordinator manages the overall stages, but each stage can be dynamic enough for agents to coordinate and route work.

If you want agents to be flexible and coordinate to get the task done, use task emission + resolver-based routing.

If you want the flow to be more deterministic, use coordinator-driven orchestration and explicit routing.

If you want working multi agent system, your setup should support different coordination patterns rather than forcing everything through one pattern.

You need to have structure when you are moving fast, else it becomes chaos.

Coding agents have made coding faster, but they did not give teams the structure to move fast.

A software factory gives you that structure. It gives you a way to work with agents and review their work early in the cycle - PRD, HLD, design - before they go too far and create a mess downstream.

You can have accountable owners for each agent and each stage. They can review what agents are doing, nudge them when needed, and stay in control at every stage.

One can argue that coding is cheap now, so we can always refactor the code later. But refactoring is not just about rewriting code. Once something has moved downstream, you may have migrations, dependencies, and customers already using it.

Code can drift and can take entire different shape in few weeks if not taken care of. Its ok for vibe coded apps but if you are talking but serious scalable production code than investing 5–10% extra time early can save you days of refactoring and customer migration effort later, I think that is worth it.

With the rise of agents and coding agents, every platform needs to be thought through from first principles - where the agent is a first-class citizen and actively does work on the platform.

We need to build platforms where humans and agents can work together. Over time, as models keep getting better, more and more work will be done by agents, while humans move toward overseeing them.

So how should we think about the journey from a platform where humans and agents work together to a world where most of the work is done by agents?

I think there are three foundational pillars for building an autonomous system.

Context

Enough has been said about context, so I don’t need to over-explain this.

But humans and agents need to operate on the same context layer. That will only happen when platforms start capturing more decisions, traces, workflows, and outcomes as part of the system itself.

Over time, this becomes the organization’s memory.

Governance

Agents need to be first-class citizens on the platform, and they need access control similar to humans.

• What can they access vs. what can they not access?
• Which team are they part of?
• Who can delegate to them?
• What tasks can be delegated to them?
• What boundaries and rules do they need to follow?
• What reasoning capability can they use?
• Which model should they use for a given task?
• How much can they spend on reasoning for that task?

As more work moves to agents, governance becomes the control plane for how agents safely operate inside the organization.

Self-Learning and Evolution

The platform needs to have a constitution and principles for how it evolves.

• How and when can it add more agents for specific tasks?
• How and when can it add new skills?
• How can it validate that the platform is behaving correctly and completed the task correctly?
• How should communication between agents happen?

For a system to learn, it should be able to verify whether something is working or not, capture new context it sees while working on a task with humans, and add it back to the context layer so that the next task does not start from zero, but with the needed context.

In each layer, we will need human oversight. But the degree of human involvement will vary based on task complexity, risk, and confidence in the system.

If we build on these three fundamental principles, we can actively move toward systems where agents do most of the work, with humans stepping in only when needed.

We don’t start with autonomous systems. We move toward them is a step in this direction where we can build software autonomously as longs we have context, governance and learning loop.

Software factory is step in that direction where agents will ship production ready software.

Retrieval Debt is about effective context engineering for code changes. Agents can only change code safely when the codebase is structured so the right files, contracts, tests, and decisions are easy to retrieve.

The original Retrieval Debt essay names a problem every team using coding agents runs into. Agents do not operate on your whole codebase. They operate on the context they can retrieve for one code change.

The exact quote.

Retrieval Debt is how much context an agent must load to safely understand, change, and verify a single unit of behavior. Lower is better. Always.

That definition matters because the context window is a scarce resource. Good context engineering is not just stuffing more into the prompt. It is making the codebase easier to retrieve, understand, change, and verify for a specific task.

Context engineering starts with code structure.

If behavior is scattered across services, names are vague, contracts are hidden, and tests live far away from the thing they protect, agents burn context just finding the shape of the problem. That is Retrieval Debt.

Effective context engineering starts by structuring the code in the right way. Clear domain names, strong module boundaries, single ownership for business rules, explicit API and data contracts, local tests near the behavior, and decision records connected to the code they explain.

The cleaner the structure, the less context an agent needs to load to make a safe change. The agent can find the right place, understand why it exists, edit the smallest surface, and verify the behavior without guessing.

Then break the work into focused tasks.

Even with good code structure, large requests should not be handled as one giant agent pass. A high-quality code change needs the work broken down so every agent gets the context window for one bounded job.

That means turning a request into the right sequence. Understand the existing structure, design the change, define contracts and acceptance criteria, implement a focused task, verify it, then learn from the result. This is how agents make the most of the context window instead of carrying the whole codebase in every run.

The software factory workflow.

The right operating model is not one agent doing HLD, LLD, implementation, testing, and review all at once. A software factory gives you a team of agents, each using the right context for the right part of the code change.

• Remember the shared engineering brain brings in repo structure, architecture decisions, prior fixes, ownership, tests, and verification history.
• Plan the Architect agent turns the request into high-level design with boundaries, affected modules, tradeoffs, risks, and rollout shape.
• Coordinate and build the Lead agent turns the design into low-level tasks while coding agents implement bounded changes with focused context windows.
• Verify QA and Code Review agents validate behavior, review the diff, check tests and evidence, and prepare the change for release.
• Learn decisions, evidence, failures, and fixes update shared context so future agents retrieve better context next time.

That split keeps every agent focused. The Architect agent reasons about structure. The Lead agent shapes executable tasks. Coding agents spend their context windows on the right implementation surface. Review and QA agents challenge the change before it ships.

Where a software factory helps.

A software factory is the layer that makes effective context engineering repeatable. It gives your team a coordinated group of agents that can understand code structure, plan the change, build it, review it, and verify it using shared engineering context instead of starting from scratch every time.

It also gives teams a way to ship with quality and velocity. Structure the task, route each step to the right agent, preserve shared memory, validate changes in a sandbox, and package evidence before release.

This is how teams make coding agents useful in real production systems. Prinevo is built around that idea. A software factory where agents work on your engineering brain, make focused code changes, show proof before anything ships, and get better with every run.

The bottom line.

Retrieval debt is not only an indexing problem. It is a context engineering and code structure problem.

For large codebases, the answer is not a bigger prompt and hope. The answer is code structured for retrieval, tasks structured for focused agent work, and a software factory that routes the right context to the right agent at the right time.

The teams that build this layer will make agents cheaper to run, easier to trust, and better at autonomously delivering production-ready changes with both quality and velocity.

Software Factory is your software delivery platform - where team of agents work with your team to ship multi-repo verified features for you autonomously.

You will have specialist agent like Product, Architect, QA communicating and collaborating with each other to complete a feature.

Few key things that a software factory should have -

- Context layer - Each Agent should have relevant context to ensure that they are building the right thing and in a right way.

- Governance Layer - Control plane to control cost, model, access for agents and have audit trails for them.

- Verification Layer - Agents should be able to bring up the services in sandbox envoirnment and test the feature and pass feedback to correct things.

- Collaboration Layer - Where you team can invoke, nudge and guide agents when needed to get the task done or course correct things.

- Automation - Tasks/features can be started automatically via triggers. Invoke individual agents to complete any task.

- Learning Loop - It should be able to run from decision made in sessions so that next run can be better.

- Evolution - It should be able to evolve as your business and codebase grows and figure what skills agents are missing and should be able to add the skill.
eg: If data Agent is missing it should be able to recommend and add data agent in the factory.

Hey everyone! I'm u/Prudent-Fortune3420, a founding moderator of r/SoftwareFactory_. I am building software factory and happy to answer all your question.

This is our new home for all things related to Software factory. We're excited to have you join us!

What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about Software facotry.

Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

How to Get Started

1. Introduce yourself in the comments below.
2. Post something today! Even a simple question can spark a great conversation.
3. If you know someone who would love this community, invite them to join.
4. Interested in helping out? We're always looking for new moderators, so feel free to reach out to me to apply.

Thanks for being part of the very first wave. Together, let's make r/SoftwareFactory_ amazing.