Topics/Enterprise Agent Evolution and Operating Model: Research Agenda
ADPS Topic Research
Enterprise Agent Evolution and Operating Model: Research Agenda
A research agenda for the concurrent evolution of agent authority, engineering platforms, and organizational responsibility.
Topics synthesize engineering questions that cross several modules. Pattern definitions, attributed cases, and workshop records remain authoritative on their own pages.
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
| Line | Typical starting point | Questions that follow |
|---|---|---|
| System authority | Read and draft | When may the agent recommend, execute, run a batch, or coordinate other agents? |
| Engineering platform | Individual tool | When are a shared harness, specification repository, test environment, event system, and common governance justified? |
| Operating model | Individual self-review | Who defines acceptance, approves authority, stewards architecture, and owns failures and long-term cost? |
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.
Questions before each increase in authority
- Business boundary. Which objects can the agent change, and what are the per-action, daily, and tenant-level impact limits?
- Acceptance ownership. Which role defines success, and which evidence comes from an independent system?
- Change authority. Which parts of code, prompts, skills, tests, specifications, and memory may the agent modify?
- Architecture ownership. Who handles dependency drift, duplication, and stale rules across tasks?
- Incident responsibility. Can execution evidence be replayed, and how do takeover and rollback begin?
- 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
For enterprises, the six questions above provide a review frame for current pilots. For ADPS, future module workshops and Blue Book cases will supply evidence. Until the body of practice is broad enough, this page will not publish a universal maturity score.
Related material
Suggested citation: ADPS, Enterprise Agent Evolution and Operating Model: Research Agenda, ADPS Topic Research, 2026-08-14.