Automating the SDLC with recursive, persistent and verifiable Agent workflows
MLAP can be used as a generic execution framework for the software development lifecycle. The SDLC structure remains stable, while the project-specific engineering hierarchy changes according to the type of system being developed.
Keep the SDLC generic; let the project structure emerge recursively
MLAP should not hard-code concepts such as frontend, backend, robot control, PLC, database or embedded firmware into the platform. Instead, the SDLC defines the development process, while Architecture and Development Agents create or manage the project-specific Agent hierarchy.
The same top-level Agent model can support very different projects
Requirements
Understand goals, constraints, acceptance criteria, risks and dependencies.
Architecture
Define components, interfaces, technologies, dependencies and project decomposition.
Development
Recursively decompose the actual software into project-specific implementation Agents.
Verification
Independently validate builds, tests, static analysis, security, integration and requirements.
Release
Build, package, approve, deploy and record release evidence.
Operations
Observe deployed systems, analyze incidents and feed knowledge back into the next development cycle.
SDLC execution is a controlled loop, not a one-pass code-generation task
When verification fails
Execution IDs and correlation IDs can track every pass through this loop, preserving what changed, what failed, what was corrected and what eventually passed.
Only the project-specific Development tree changes
Example: Web Application
Example: Equipment Control System
MLAPCore remains unchanged in both cases. The Architecture Agent determines the appropriate engineering decomposition for the project.
The Agent that creates an artifact should not be the only Agent deciding whether it is correct
Build Validation
Compiler, build tools and packaging checks.
Automated Tests
Unit, integration, system and regression tests.
Static Analysis
Linters, code analyzers, dependency and security scanners.
Simulation
Domain-specific simulators for equipment, embedded or integration-heavy systems.
Requirement Validation
Check implementation evidence against acceptance criteria.
Review
Structured technical review using tools, rules and optional LLM reasoning.
Use LLM reasoning where interpretation is needed; deterministic systems where verification is possible
| LLM-oriented work | Deterministic work |
|---|---|
| Requirements interpretation | Compilation and builds |
| Architecture reasoning | Unit / integration / regression execution |
| Code generation and refactoring | Static analysis and linting |
| Code review and explanation | Security and dependency scanning |
| Failure interpretation | Simulation and protocol validation |
| Documentation and summaries | Git operations, packaging and deployment |
Agents exchange status and meaning; artifact systems store the real engineering outputs
MLAP messages contain
- status
- summary
- findings
- confidence
- risks
- recommendations
- artifact references
Artifact systems contain
- source code
- Git commits / branches
- design documents
- test reports
- build packages
- logs and simulation output
- release packages
Persistent context prevents every Agent from rediscovering the project on every execution
ProjectKnowledge can continuously learn from requirements, design documents, source code, Git history, issues, test results, release notes, incidents and operational logs. Specialist Agents query only the context relevant to their task.
Developer query
“What conventions exist for API error handling in this project?”
Architecture query
“Which components depend on CustomerService?”
Testing query
“Which defects repeatedly occur in this module?”
Operations query
“Has this production failure occurred in an earlier release?”
Automation does not remove engineering approval
Approval depth can vary by project. A prototype may use minimal gates; industrial, regulated or safety-related systems can require architecture, validation, security, lab or release approvals.
Maintain the relationship from requirement to release evidence
Operations feeds the next development cycle
The development process therefore becomes continuous: understand, design, implement, verify, approve, release, observe, learn and repeat.