Working model · v0.1

Evolution of Agentic Engineering

A working model by Orlando Garcia
August 2026

A model for reasoning about how software engineering may evolve from individual coding agents toward systems of specialized, cooperating engineering capabilities — and the DevEx conditions required for that evolution to scale.

The model

From agents to engineering systems

01

APPARITION

Agents become viable engineering actors: they interpret intent, explore repositories, use tools, modify software, execute commands and iterate.

02

MUTATION

Agent configurations proliferate: models, tools, context strategies, permissions, subagents, swarms and orchestration patterns.

03

SELECTION

WORKING HYPOTHESIS

Engineering environments determine what can scale. Fit configurations produce useful outcomes without proportional growth in cost, risk or human attention.

04

COOPERATION

Fit agents compose into complex workflows: work is divided, state is exchanged, capabilities combine and coordination becomes an engineering problem.

05

SPECIALIZATION

Repeated cooperation produces stable, differentiated capabilities with distinct context, tools, authority, interfaces and evaluation criteria.

Working hypothesis: agentic engineering may be entering Selection.
Selection

The environment becomes part of the fitness function

The useful question is not which agent mutation will win, but which engineering conditions allow useful configurations to succeed and scale.

Candidate DevEx conditions. Context, Execution and Verification are one current area of exploration, not an organizational roadmap.

CONTEXTCan agents efficiently acquire sufficient knowledge?
EXECUTIONCan agents safely and reproducibly perform engineering work?
VERIFICATIONCan agents produce trustworthy evidence of correctness?
COORDINATIONCan parallel work compose without coordination cost dominating?
OBSERVABILITYCan humans understand behavior, outcomes and exceptions?
ECONOMICSDo compute, tools, CI and human attention remain viable?
LEARNINGDo failures improve the environment for future executions?
Agentic-system fitness = useful outcome / ( context + execution + coordination + verification + human attention + compute )
The forcing function

What breaks at 1K agents?

1K agents is not a utilization target. It is a stress test for DevEx design. Small inefficiencies become systemic when multiplied across an agent population.

1K-agent scale = amplify( friction + ambiguity + risk + coordination + cost )
Expensive context exploration × 1Kbecomes systemic waste
Non-reproducible execution × 1Kbecomes operational instability
Human-dependent verification × 1Kbecomes a throughput ceiling
Coordination conflicts × 1Kcan erase the benefit of parallelism
Opaque agent behavior × 1Kmakes failures and exceptions impossible to understand
Unbounded execution cost × 1Kturns small inefficiencies into unsustainable economics
Repeated failures × 1Kcompound unless every execution improves the system
One way to apply the model

Engineer DevEx for 1K-agent scale

A practical starting point is the minimum engineering loop: acquire → execute → verify.

CONTEXT · acquire sufficient knowledgeEXECUTION · perform work safelyVERIFICATION · establish trustworthy evidence

The 1K constraint asks whether each capability remains viable as agent populations grow. Which conditions matter most — and in what sequence — should follow evidence rather than a roadmap assumed in advance.

Where this could lead

Cooperation before specialization

When sufficiently fit agents can cooperate repeatedly, stable, differentiated engineering capabilities can emerge.

Specialization may live in roles, context, tools, authority, memory, interfaces and evaluation criteria — not necessarily in different models. The engineer increasingly composes capabilities rather than treating every agent as interchangeable.

Test the hypothesis

Is agentic engineering entering Selection?

Possibly — this is a hypothesis to test, not a conclusion.

Agent architectures are still mutating rapidly. But as organizations increase agent concurrency, recurring constraints become more consequential: context, execution, verification, coordination, observability, economics and learning.

The hypothesis is that these constraints increasingly influence which agentic engineering approaches can scale. 1K-agent scale is a forcing function for testing that idea.

Signals from the industry

Are independent systems encountering the same pressures described by this model?

Public evidence does not establish the evolutionary sequence — or that any company can operate 1,000 coding agents concurrently. But independent engineering organizations are encountering similar problems that this model groups under Selection: context, isolated execution, verification, coordination, observability and durable operation.

Strong signal

Spotify

Honk runs many concurrent sessions in Kubernetes, verifies changes in CI, integrates with fleet orchestration, and is evolving toward shared sessions and agent orchestration. Spotify reports 99%+ weekly AI-tool adoption and fleet-wide migrations completed by a single engineer in days.

ApparitionMutationSelectionCooperation ↗Specialization ?
Public evidence ↗
Strong signal · boundary refinement

OpenAI · Symphony

OpenAI found that engineers could comfortably manage only 3–5 simultaneous Codex sessions before context switching reduced productivity. Symphony moves coordination into an always-on orchestrator where open tasks receive agents in isolated workspaces; OpenAI reports a 500% increase in landed PRs on some teams.

ApparitionMutationSelectionCooperation ↗Specialization ?
Public evidence ↗
Strong signal

Cursor

Cursor is moving from single-agent interaction toward fleets of async subagents, parallel plans and isolated worktrees. Its own framing describes a future where fleets of agents work autonomously to ship improvements.

ApparitionMutationSelectionCooperation ↗Specialization ?
Public evidence ↗
Selection signal

Google

Google's Agent Executor was created because long-running agent workflows exposed reliability and efficiency problems. Durable execution, event logs, snapshots and resumption become runtime infrastructure rather than agent-level concerns.

ApparitionMutationSelectionCooperation ?Specialization ?
Public evidence ↗
What this evidence lets us say
  • Independent organizations are encountering similar scaling constraints.
  • Infrastructure around agents becomes more important as concurrency and autonomy increase.
  • Some public evidence is consistent with a possible Selection → Cooperation transition.
  • It does not establish that Spotify, OpenAI, Cursor or Google can operate 1K coding agents concurrently. 1K remains a stress test in this model, not an industry benchmark.

Explore the living evidence record →

Apply the model

Can you engineer for 1K-agent scale?

Use 1K agents as a forcing function for your engineering decisions. Pick the condition closest to your work and ask what breaks when usage increases by orders of magnitude.

CONTEXTWould 1K agents find what they need?
EXECUTIONCould 1K agents safely run?
VERIFICATIONCould we trust 1K outcomes?
COORDINATIONCould 1K agents work without overwhelming each other?
OBSERVABILITYCould we understand what 1K agents are doing?
ECONOMICSCould we afford it?
LEARNINGWould agent 1,001 benefit from what the first 1,000 learned?

Find what breaks. Engineer the condition.

Then turn the constraint you find into an engineering expectation.

Evidence & open questions

A working model, not a prediction

The purpose of the model is to generate useful engineering questions. It should change when evidence contradicts it.

What would challenge the model?
  • Large-scale agentic engineering succeeds without the proposed selection conditions.
  • Cooperation reliably precedes context, execution or verification maturity.
  • Different constraints become dominant as agent populations scale.
  • Stable specialization does not emerge from repeated cooperation.
Origins

Thinking lens

This model was developed using Daniel San Martín's Clarity model as a thinking lens, particularly its progression through Apparition, Mutation, Selection, Cooperation and Specialization.

The application of those ideas to agentic software engineering—including the interpretations and hypotheses presented here—is my own.