Autonomous Systems Engineering: Architecting Agentic SDLCs with System Spiders and Smart Swarms

Software modernization becomes hardest when the system that matters most is the system nobody can fully explain.

Legacy applications often survive because they encode years of business decisions in UI validation, stored procedures, integration scripts, runtime configuration, undocumented conventions, and production-only edge cases. The problem is not simply old code. It is missing operational knowledge: the distance between what stakeholders believe the system does and what the running system actually does.

The blueprint presented here treats that gap as an autonomous systems engineering problem. Instead of asking a single model to understand an entire estate from source code alone, it separates the work into two complementary capabilities. System Spiders observe and normalize ground-truth behavior. Smart Swarms use that evidence to plan, migrate, test, diagnose, and repair changes. A shared blackboard provides persistent state between the two.

The result is not an AI coding assistant scaled up. It is an architecture for turning ambiguous systems into progressively formal, testable, and governable software delivery loops.

1. The Real Legacy Problem Is an Abstraction Gap

A low-documentation monolith is deceptive because its visible application boundary suggests a single system while its real behavior is distributed across layers. Validation may live in the UI, business invariants may be embedded in stored procedures, transformations may be hidden in ETL scripts, and production configuration may change semantics without changing source.

This creates an abstraction gap between business intent and executable behavior. Traditional reverse engineering usually starts from code and works upward, but code is only one evidence source. If critical rules emerge from database state, integration timing, runtime flags, or client behavior, a code-only model can produce a clean explanation of an incomplete system.

The engineering consequence is important: modernization cannot begin safely with generation. It must begin with discovery.

A useful discovery process should answer questions such as:

• Which requests and user flows are exercised in production?
• Which data shapes and constraints appear at runtime?
• Which database objects actually participate in those flows?
• Which validation rules are enforced outside the nominal service layer?
• Which failures, retries, and edge paths affect observable behavior?

The diagram's "solution mandate" is therefore best read as an architectural requirement: requirements recovery must be automated enough to follow actual execution paths, not limited to manually reconstructed documentation.

2. Bridge Ambiguous Intent into Formal Execution

Business requirements naturally begin in an informal domain: natural language, user stories, stakeholder vocabulary, and incomplete assumptions. Execution environments live at the opposite end: typed interfaces, schemas, constraints, code, tests, and deterministic pass/fail conditions.

The bridge between those domains is where agentic reasoning is most useful. A goal-directed agent can decompose intent, ask what evidence is missing, map observations to formal representations, and iterate when a candidate specification conflicts with runtime facts.

The important design choice is to avoid treating the agent's prose as the final specification. The output should move toward artifacts that software systems can verify: API contracts, schemas, UML or other structural models where appropriate, constraint expressions, executable tests, and code.

This establishes a practical rule for agentic SDLCs:

Reasoning may be probabilistic, but acceptance criteria should become increasingly deterministic as work approaches execution.

That distinction controls risk. Early phases can tolerate ambiguity because the purpose is exploration. Later phases should narrow the solution space until a compiler, test suite, schema validator, policy engine, or human reviewer can make a concrete decision.

3. Autonomy Requires a Design-Pattern Ladder

Agentic systems do not become production-ready merely by adding more agents. Capability increases together with coordination complexity, state-management requirements, and failure modes.

The progression in the blueprint can be read as four architectural stages:

1. Foundation — single-agent prompt chaining. Useful for bounded, linear tasks where each step has one obvious successor.
2. Routing — dispatch to specialized endpoints. Introduces task classification and delegation so different capabilities can own different problem types.
3. Memory and planning — persistent state plus iterative reasoning. Allows work to span multiple turns, recover context, and revise a plan.
4. Smart Swarms — peer-oriented multi-agent orchestration. Specialized workers can coordinate dynamically rather than following one rigid central script.

Each stage earns its complexity only when the problem requires it. A deterministic transformation does not need a swarm. A migration involving code semantics, environment provisioning, test generation, failure diagnosis, and iterative remediation probably does.

The key production question is therefore not "How many agents should we use?" It is "What coordination pattern matches the dependency structure of the work?"

The slide frames orchestration as the difference between prototype and production. Whether or not one adopts that wording literally, the underlying engineering point is strong: production autonomy depends on explicit state, routing, retry, termination, and validation semantics.

4. System Spiders Turn Runtime Behavior into Evidence

The discovery half of the architecture uses specialized "System Spider" nodes to collect ground truth from different surfaces of the legacy system.

The blueprint highlights three complementary sources:

• Traffic capture observes HTTP/S and gRPC payloads while filtering irrelevant background activity.
• Catalog extraction inspects relational metadata such as system tables and information schemas.
• UI flow mapping follows user interactions and dynamic DOM behavior to recover how the front end actually drives the system.

No single source is sufficient. Traffic reveals real inputs and outputs but may not explain persistence. Database catalogs reveal structural relationships but not which paths are active. UI crawling reveals journeys but not every backend side effect. Combined, they form a richer behavioral model.

This is the first major separation of concerns in the design: observation agents should not be the same thing as transformation agents. Discovery nodes are optimized to measure the existing system; migration nodes are optimized to propose changes.

That separation reduces a common source of agent error. When one model both infers current behavior and invents the replacement in the same reasoning chain, assumptions can silently become "facts." A discovery layer produces evidence that downstream agents can reference instead.

For production use, capture also introduces security obligations. Payloads, schemas, and UI traces can contain credentials, personal data, or regulated information. A real implementation should therefore apply minimization, redaction, access control, retention limits, and auditability at the collection boundary.

5. Normalize Dynamic Traces into Stable Contracts

Raw runtime traffic is noisy. The same logical route may appear with thousands of concrete IDs, timestamps, optional fields, and contextual variations. Agents cannot reason efficiently if every observation is treated as a unique interface.

The normalization stage converts concrete observations into reusable structure. A family of paths such as /v1/users/8391/billing and /v1/users/1204/billing can be generalized into /v1/users/{user_id}/billing. Request and response samples can be clustered to infer field types, optionality, nullability, authentication expectations, and recurring schema variants.

This is more than log cleanup. It is a form of operational specification mining.

A useful normalized artifact should retain two kinds of information at once:

• the generalized contract that downstream agents can consume; and
• enough provenance to trace that contract back to the observations that produced it.

Without the first, the system remains too noisy to automate. Without the second, a generated requirement cannot be challenged or audited.

Normalization is also where confidence should be made explicit. A route observed ten thousand times is not automatically more "correct" than a rare path, and absence of an event is not proof that the behavior does not exist. Good discovery systems record support, exceptions, and uncertainty rather than collapsing every cluster into a universal rule.

6. The Blackboard Is the Coordination Center

Once discovery produces normalized evidence, the architecture needs a shared place for agents to read and write state. The blueprint uses a blackboard architecture for this purpose.

The left side posts ground-truth telemetry, APIs, schemas, and UI flows. The center stores validated state. The right side contains specialized coding, review, and testing agents that read the board, perform work, and post results back.

This pattern solves several coordination problems at once.

First, it limits the "telephone game" effect of long agent-to-agent message chains. Instead of every worker passing an increasingly lossy summary to the next worker, each agent can read shared state directly.

Second, it changes communication complexity. In an unconstrained peer network, coordination can trend toward pairwise interactions between many agents. A shared board allows agents to coordinate through a common substrate rather than maintaining bespoke conversations with every other participant.

Third, it creates a natural control point. The blackboard can store not only content but also status, confidence, provenance, locks, approvals, attempt counts, test results, and policy decisions.

The control shell around the board is therefore as important as the board itself. Production autonomy requires rules about who may update which state, how conflicts are resolved, when work is considered stale, and what conditions move an item from observed to inferred to validated to approved.

A blackboard should not become an unstructured dumping ground. Treat it as a typed state machine, not a shared chat transcript.

7. Put the Environment Inside the Reasoning Loop

Software transformation cannot be validated in language alone. Code has to compile, dependencies have to resolve, services have to start, tests have to run, and runtime behavior has to match expectations.

The blueprint separates three responsibilities:

• M-Agent (Migration) interprets legacy semantics and proposes modern code and dependency manifests.
• E-Agent (Environment) provisions isolated execution environments, configures toolchains, and builds the application.
• T-Agent (Testsuite) creates and maintains regression tests and executes them in the provisioned sandbox.

This structure makes the environment an active participant in reasoning. Compiler output, package-resolution errors, test failures, and runtime exceptions become evidence for the next decision.

That is a significant architectural shift from "generate code and hope." The autonomous loop becomes:

propose → provision → execute → observe → revise

Isolation is essential. Generated code should not inherit unrestricted access to production networks, secrets, repositories, or infrastructure. Sandboxes should have narrow credentials, explicit egress rules, bounded compute, reproducible dependencies, and clean teardown semantics.

The environment node also provides a path to reproducibility. If every remediation attempt runs inside a defined toolchain and dependency set, a successful result is easier to replay and promote than a result produced in an opaque developer workstation state.

8. Reflection Loops Make Failure Actionable

Autonomy is useful only if failures become structured input rather than dead ends. The swarm reflection loop in the blueprint treats compiler and test failures as signals to diagnose, route, repair, and rerun.

The loop contains three stages.

Diagnostic extraction converts runtime errors, compiler messages, stack traces, and test output into a structured representation. This step matters because raw logs are verbose, inconsistent, and often contain multiple symptoms for one root cause.

Targeted remediation then routes the failure to the appropriate specialist. Semantic defects go back to the migration agent, environment or dependency faults go to the environment agent, and behavioral mismatches may require the test agent to refine an invalid test or expose a genuine requirement gap.

Iterative verification redeploys the candidate into an isolated sandbox and repeats the checks until a clean exit or a control limit is reached.

The phrase "self-healing" should not imply unbounded retries. A robust loop needs explicit termination conditions: maximum turns, timeouts, budget ceilings, duplicate-failure detection, and escalation paths. Otherwise a swarm can spend unlimited compute oscillating between equivalent fixes.

A mature system also distinguishes repairing the implementation from weakening the test. The test suite is part of the specification. Changing it should require stronger justification than changing code merely to achieve a green build.

9. Choose the Orchestration Framework by Control Requirements

The blueprint compares three orchestration approaches: CrewAI, LangGraph, and IBM's BeeAI. The useful lesson is not that one framework wins universally; it is that orchestration technology should match the required control model.

The slide characterizes them this way:

• CrewAI emphasizes role-based collaborative behavior among specialized agents.
• LangGraph emphasizes graph-based, stateful workflows with explicit memory and human-in-the-loop patterns.
• BeeAI emphasizes modular workflows and enterprise-oriented integration and telemetry.

Those descriptions point to a practical evaluation matrix. Teams should compare frameworks on:

• state persistence and replay;
• deterministic routing and branching;
• human approval hooks;
• tool permission boundaries;
• event and trace visibility;
• checkpointing and recovery;
• concurrency controls;
• deployment model;
• framework lock-in;
• testability of orchestration logic.

The more autonomous the system becomes, the more important it is that the orchestration layer be observable and inspectable. A framework that makes a compelling demo but hides state transitions will be difficult to operate during a migration incident.

In other words, choose for control, debuggability, and lifecycle fit, not for the shortest path to a multi-agent prototype.

10. Governance Must Be Part of the Data Model

A self-modifying or self-remediating delivery loop needs stronger traceability than a conventional assistant because it can make many linked changes without a human writing each one.

The blueprint proposes cryptographic linkage across a requirement identifier, module path, and AST node identifier, producing a SHA-256 trace hash. The intent is to maintain a verifiable chain between a business requirement, the code location that implements it, and the agent-produced artifact associated with that transformation.

This is valuable because modernization often fails at explanation rather than generation. A team may receive functioning code but still be unable to answer:

• Which legacy behavior justified this new rule?
• Which requirement does this module implement?
• Which agent changed it?
• Which tests validated the change?
• What evidence was available when the decision was made?
• Who approved promotion?

A cryptographic hash can support tamper evidence, but it is not a complete governance system by itself. The surrounding control plane still needs identity, authorization, signed events or equivalent audit records, protected storage, and policy enforcement.

The human-in-the-loop gate in the diagram adds operational limits such as maxTurns, hard timeouts, mandatory validation checkpoints, and human sign-off before production merge. These are not anti-autonomy features. They are what make autonomy governable.

A well-designed control plane defines where human judgment is mandatory and where machines are free to iterate.

11. Read Performance Claims as Hypotheses to Reproduce

The final slide presents an "agentic dividend" using several quantitative claims: a 42% lead-time reduction, a 60% reduction in invalid test cases, an 84.7% recall rate for unclassified vulnerability discovery, and a statement that 75% of real-world GitHub issues in SWE-bench Verified are resolvable by top autonomous models.

Those numbers are part of the source material, but the supplied images do not include the underlying study design, datasets, confidence intervals, baselines, sampling rules, or reproducibility details. They should therefore be treated as reported benchmark claims rather than independently verified results.

For an engineering organization, the more useful response is to turn each claim into an internal experiment.

For lead time, define exactly where the clock starts and stops and compare equivalent work categories. For invalid tests, distinguish agent-generated false assumptions from legitimate regression discoveries. For vulnerability recall, establish a labeled evaluation set and measure precision as well as recall. For issue-resolution benchmarks, compare task mix and environment constraints with the organization's own repositories.

The architecture should stand even if the exact percentages change. Its core value proposition is structural: better discovery, formalized state, environment-grounded execution, specialized remediation, and governed coordination.

Engineering Principles

The architecture ultimately depends on several principles:

1. Discover before generating.
   Legacy modernization should begin with observed behavior across traffic, data, UI, configuration, and execution—not with assumptions derived from source code alone.

2. Convert ambiguity into executable checks.
   Natural-language reasoning is useful for exploration, but acceptance should converge on schemas, builds, tests, constraints, and policy gates.

3. Use shared state instead of long conversational chains.
   A typed blackboard preserves provenance, reduces context degradation, and gives every agent a consistent view of system state.

4. Make the environment part of the agent loop.
   Compilers, sandboxes, dependency resolvers, and test runners provide objective feedback that language models cannot simulate reliably.

5. Bound autonomy with governance.
   Turn limits, timeouts, isolated permissions, audit trails, cryptographic linkage, and human approvals are part of the architecture, not post-production add-ons.

6. Route failures to the right specialist.
   Semantic, environmental, and behavioral failures require different remediation strategies. A swarm is most effective when responsibility is explicit.

7. Preserve provenance through normalization.
   Generalized contracts are useful only when teams can trace them back to the runtime evidence that produced them.

8. Measure the system, not the demo.
   Production evaluation should track successful task completion, retry depth, human interventions, false repairs, regression quality, cost, latency, and rollback frequency.

Final Synthesis

The HWMAN blueprint can be understood as a two-sided autonomous SDLC around a governed state core.

System Spiders occupy the evidence side. They observe real traffic, database structure, and UI behavior, then normalize those traces into machine-consumable operational specifications. Smart Swarms occupy the transformation side. They read validated state, plan changes, generate code, provision environments, build tests, diagnose failures, and iterate toward an accepted result.

The blackboard connects these halves without forcing every agent to maintain direct conversational context with every other agent. The environment loop provides objective execution feedback. Reflection loops turn failures into routed remediation tasks. The control plane constrains iteration and preserves traceability.

The production-ready system therefore combines:

• Deterministic foundation: normalized contracts, typed state, builds, schemas, and executable acceptance criteria.
• Testing layer: generated and maintained regression suites executed in isolated environments.
• Agent and AI layer: specialized discovery, migration, environment, testing, review, and diagnostic agents.
• Security and governance: sandboxing, permission boundaries, traceability, bounded turns, approval gates, and audit records.
• Observability layer: captured telemetry, blackboard events, execution traces, error classifications, and orchestration state.
• Production outcome: a modernization process that can explain what it observed, why it changed something, how it validated the result, and where human accountability applies.

The most important architectural move is the separation between knowing the system and changing the system. Discovery creates evidence. The blackboard turns evidence into durable state. Swarms act on that state. Environments verify the action. Governance decides when the result is trustworthy enough to advance.

Closing Thought

Autonomous software engineering is not achieved by giving a model more freedom. It is achieved by building a system in which freedom is surrounded by evidence, execution, state, and controls.

The path to reliable agentic SDLCs is not more conversation—it is better architecture around the conversation.