Topics/Enterprise Agent Evolution and Operating Model: Research Agenda

When an agent moves from a personal assistant into a shared workflow and gains authority to change business state, the architecture is only one part of the transition. Review accountability, incident handling, knowledge maintenance, cost management, and team responsibilities also change.

ADPS patterns address local architecture problems, cases document concrete practice, and workshops preserve first-hand practitioner observations. How an enterprise combines these pieces and expands autonomy over time remains less settled. This page therefore starts as a research agenda: it defines the questions and the evidence still needed.

Three concurrent lines of evolution

The three lines do not advance automatically in step. A system may support autonomous execution before the organization has defined acceptance ownership or incident response. A platform may also centralize too early, before stable use cases and reusable assets exist.

From one change to an agent fleet

The payroll example on the home page defines the minimum modelling unit as one business change that can be decided, approved, executed, accepted, and compensated independently. That unit closes one piece of work. The governance lifecycle manages how a capability moves through registration, evaluation, shadow operation, production, revalidation, demotion, and retirement.

Observability joins facts across the five scales. Evals and tests support release decisions; governance controls changes in authority. Without a clear minimum loop, a platform can accumulate entry points, tools, and logs without establishing who accepts a completed business change.

Questions before each increase in authority

1. Business boundary. Which objects can the agent change, and what are the per-action, daily, and tenant-level impact limits?
2. Acceptance ownership. Which role defines success, and which evidence comes from an independent system?
3. Change authority. Which parts of code, prompts, skills, tests, specifications, and memory may the agent modify?
4. Architecture ownership. Who handles dependency drift, duplication, and stale rules across tasks?
5. Incident responsibility. Can execution evidence be replayed, and how do takeover and rollback begin?
6. Economic boundary. How are model, tool, review, test, and rework costs considered together?

Technical capability alone does not justify a wider authority boundary. Each level also needs matching acceptance, observability, rollback, and organizational responsibility.

Intended outputs

• An enterprise autonomy scale that identifies the actions and prerequisites at each level.
• A role and responsibility map across business, engineering platform, security, data, risk, and operations.
• Admission criteria from pilot to production, including evidence, budget, authority, and incident readiness.
• A taxonomy for incidents and slow degradation, separating individual failure, memory contamination, architecture drift, and organizational mismatch.
• Comparative cases showing how the same principles change across industries and risk levels.

How to use this page now

Enterprises can use the six questions above to review current pilots. Future ADPS workshops and engineering case reports will add evidence. A universal maturity score would require a broader body of observed practice.

Related material

• AI-Driven Software Engineering
• ADPS Pattern Matrix
• Governance module and agent lifecycle
• First Governance Module Workshop
• ADPS Enterprise Cases
• ADPS Workshops

Edit source · Published source · Review process