“Retroactive architecture” — a new idea in IT?

Everyone is shipping AI now. Agents, assistants, automation. Some as a markdown file with a system prompt. Others as GPTs in OpenAI. Still others as internal pipelines wired through APIs.
On paper it is a plan. In practice it looks different.

Sales configured their assistant three months ago. Customer service runs another, built by an external vendor. IT launched a document pipeline that “works, but nobody knows exactly how”. Someone in marketing uses a GPT with instructions pasted into the system field — no documentation, no owner.

No one knows what they have. No one knows what duplicates what. No one can answer the simplest question: what AI resources are running in this organization today?

We have seen this moment before

It looked exactly like the early years of ERP. Every department had its Excel, its Access database, its own way to do the same job. Data was everywhere and nowhere. Only when coordination cost exceeded the cost of order did organizations start to build structure.

With AI we are in the same place — only the clock runs ten times faster.

Architecture usually comes before the system

That is how we are taught to design. Schema first, then build. Contract first, then integration.

Most organizations never had time for that luxury. Deployments followed market pressure, pilots, “let’s see what happens”. The system grew without a plan.

What you have in your organization today is not architecture. It is an as-is environment.

For environments like that we lack a word. We lack a method. We lack a tool that answers: what do we actually have here, and how does it work?

Retroactive architecture is not about going backwards. It is reconstructing the logic from a running system. You do not start by asking how it should be. You ask how it is, and why — and only then decide what to change.

It is closer to archaeology than to greenfield design.

What this means for AI agents

When you hire a human, you enter them into a system. Role, scope, competencies, manager, status.

When you deploy an AI agent, you have none of that.

You have a tool. It may work. It may not. Someone configured it six months ago. That person no longer works here.

Organizations are building fleets of agents with no governance. One team buys Copilot. Another builds a GPT-4o pipeline. A third uses Make.com for mail automation. No one knows what duplicates what, what is active, or what runs without oversight.

This is not a technical problem. It is an organizational problem that does not have a name yet.

There is no inventory. No vocabulary. No place where a COO could ask: what AI resources do we have for this process?

We started looking for a name for that gap.

We called it

AIRS — AI Repository of Skills.

A system that records not tools, but competencies. Not “we have a chatbot”, but “we have an agent that can: read invoices in format X, escalate to department Y when condition Z applies, in the context of our Comarch ERP”.

Every agent has six attributes:

• Agent — who: name, model, business-side owner.
• Skills — what it can do: concrete tasks, not vague categories.
• Context — where it operates: ERP, CRM, WMS, external APIs.
• Constraints — what it must not do; when it escalates to a human.
• Owner — who is accountable operationally, not just technically.
• Status — active, in pilot, retired.

That is closer to an operational resource catalogue than an IT asset register. And that is why it is not a standard yet — IT thinks of agents as infrastructure; operations lack language to name them. AIRS provides that language.

Why this matters now

An agent inventory built today costs a fraction of an audit done after the fact.

If your organization is rolling out AI and no one can answer what AI resources we have for this process — this is exactly what you are missing.

Next post: why HRMS does for people what no one yet does for agents — and what the inventory model looks like that changes that.

AIRS — AI Repository of Skills →

Start with one question: how many AI agents run in your company today, and who is operationally accountable for each? If the answer is hard — let’s talk.