From Platform Engineering to Software Factories and Agentic Organizations

I spent 15 years building infrastructure and developer platforms, most recently leading a Kubernetes platform team. Over that time, I kept seeing the same problem appear in different forms: once a process becomes too fast or too complex to run through human-driven queues, adding more management rarely helps. You need self-service, clear boundaries and automated guardrails.

That thinking eventually led me to found Accession1. It is also why I’m now working alongside re:cinq on client engagements.

To be clear, I’m not joining re:cinq as an employee. This is a delivery partnership between Accession1 and re:cinq. We have worked together for years in cloud native and platform engineering, and we’re now bringing that experience together again as software delivery starts changing around AI agents.

I see software factories and agentic organizations as closely related. As agents take on more execution, workflows begin to outgrow the approval queues and manual handoffs they were built around. At the same time, the systems those agents use need to work together around the way the organization actually operates.

Software engineering encountered many of these problems first. Platform engineering was one of the answers. Software factories build on that foundation and take it further, extending beyond the traditional SDLC into more of the product development lifecycle and adapting the whole system to work at agentic speed.

Working with re:cinq gives me the opportunity to test those ideas against real production environments rather than only reason about them from the outside.

What platform engineering taught me

Software delivery was one of the first business processes where the traditional ticket queue stopped working.

Engineers could not wait days for database credentials, environments or deployment approvals every time they needed to move. Platform engineering emerged partly as a response to that: give teams self-service access to the things they need, while putting the right controls underneath.

But self-service was only half the job.

A typical platform might combine a cloud provider, CI system, secrets manager, observability stack and a long list of other tools from different vendors. Each could work perfectly well on its own while knowing almost nothing about the others.

The platform team had to turn all of that into one usable system. It had to fit the company’s compliance requirements, team structure and way of delivering software. Two organizations could use almost exactly the same technology and still need very different platforms.

That is the lesson I carried forward. Platform engineering showed that work can move much faster without giving up control, but only when the underlying platform is designed around the organization using it.

That principle now applies well beyond infrastructure.

From platform engineering to software factories

Traditional platform engineering addressed the part of software delivery where the queue broke first: infrastructure, environments and deployment.

Software factories push much further upstream.

They change how the product and software development lifecycle work once agents become part of the delivery system: how intent is captured, how work is broken down and delegated, where agents execute, how they receive access, how their work is validated and where people still need to make decisions.

This is the area re:cinq focuses on with clients.

Software engineering is a useful place to see this transition early because it already has relatively strong feedback loops, automated tests, version control and detailed instrumentation. We can observe what happens when agents begin doing real work rather than only assisting a person.

That makes software factories useful for another reason: many of the problems appearing there today are likely to appear elsewhere in the organization next.

From the software factory to the agentic organization

AI agents will not remain limited to engineering.

They will increasingly work across finance, operations, legal, customer support and other parts of the enterprise. When that happens, those functions will run into many of the same constraints software teams already encountered.

Imagine an agent that can complete a complex analysis in twenty minutes but needs access to an internal system that takes three days to obtain through a ticket.

The intelligence of the agent is no longer the bottleneck. The organization around it is.

And because agents can operate continuously across chains of work, those queues become even more expensive. A slow approval does not delay one isolated task; it can block everything that depends on it.

There is also an integration problem.

An agent working in finance might need an ERP, document store, CRM and identity provider. None of those systems necessarily understand one another, and none understands the specific way that company approves spend, handles exceptions or assigns authority.

Someone still has to turn those tools into a coherent system and fit it around the way the organization operates.

Platform teams have already been doing a version of this for developers for years.

A software factory is therefore one specialized part of a much broader agentic organization. As agents spread into other functions, I expect the same principles to follow them: self-service provisioning, dynamic access, automated guardrails and platforms built around organizational context rather than individual tools.

Why Accession1 and re:cinq are working together

The re:cinq team and I go back years through platform engineering and cloud native, so there is a lot of shared context behind this partnership.

We also approach the current shift from complementary directions.

⁠re:cinq focuses on how software delivery and the organization around it change when agents begin taking on execution: the PDLC, SDLC, operating model, delegation boundaries and the way humans and agents work together.

My focus through Accession1 is closer to the infrastructure underneath that shift: how self-service provisioning, access management, integration and platform controls need to evolve when the users are increasingly agents rather than only people.

That is why the collaboration happens in client delivery rather than only in discussions between our two companies.

⁠re:cinq leads the engagements and brings the experts delivering the AI-native transformation. I work alongside them where my platform engineering background can add to that work.

For me, that also means seeing the real friction firsthand: where agents genuinely speed things up, where they get stuck, where people still have to intervene and how much of the surrounding platform needs to be designed around the specifics of each organization.

There is still plenty we do not know.

One of the questions I’m particularly interested in is how delegation boundaries should be designed so that people and agents can operate safely inside the same system without recreating the approval queues we spent years removing from software delivery.

I expect the useful answers to come from doing the work with real teams, not from drawing an ideal architecture on a whiteboard.

Why platform engineering will shape the agentic organization

If you spent the last decade in cloud-native infrastructure, DevOps or platform engineering, I think you are much closer to the agentic transition than it may initially appear.

The principles we developed — self-service, guardrails, policy as code, continuous reconciliation and strong platform integration — were all responses to a similar problem: how to let work move faster without losing control.

Agents bring that problem to a much larger part of the organization.

My bet is that many of the ideas developed in platform engineering will become part of the foundation of the agentic organization.

Software factories are where we can start testing that bet today, which is exactly why I’m excited to be working with re:cinq on the client work where those lessons are already starting to emerge.