Progress-driven Unified Living System Engine
Status: Conceptual definition v0.1 — Private development
Started: June 2026
PULSE is a framework for building AI agent systems that reason about the real state of the domain to guide their own execution and evolution.
Current agent frameworks know whether they executed their steps. PULSE knows whether the work is actually done well.
Every significant effort has dimensions that need to progress and stay healthy — not just tasks to complete. PULSE models those dimensions as Alphas: formal state indicators with verifiable checkpoints. Agents don't just execute — they evaluate whether their work has genuinely advanced those states before moving forward.
Like a doctor who checks your actual health before prescribing the next treatment — not just whether you followed the previous prescription.
Today's agent frameworks share a structural blind spot: they detect artifact existence, not work quality.
A workflow generates an architecture document. The system marks the phase complete. Nobody verifies whether that document actually addresses the identified risks, is coherent with requirements, or is detailed enough to build on. The project advances on an unvalidated foundation.
PULSE replaces "did the file get created?" with "do the domain checkpoints pass?"
PULSE synthesizes two established systems:
The Object Management Group standard for software engineering methods. Contributes:
- Alpha: Abstract-Level Progress Health Attribute — a thing whose state you need to understand to know how the project is going. Has progressive states with verifiable checkpoints.
- to_do():
to_do(alpha, target_state) → Set<Activity>— given an Alpha's current state and a target, computes which Activities need to execute. State-driven, not sequence-driven. - Practice: a formally closed, composable package of Alphas + Activities + Work Products + Competencies. Practices compose algebraically.
- Activity Space: a work container defined by Alpha-state entry and completion criteria. Closes when the world reaches the target state, not when steps finish.
The most adopted open-source AI agent framework (43K+ GitHub stars). Contributes:
- Skill / SKILL.md: the universal execution unit
- Agent types: stateless, memory, autonomous
- Sanctum: persistent agent memory across sessions
- Module system: installable, composable skill bundles
- bmad-help: project navigator (extended by PULSE-Help)
PULSE takes Essence's formal state model and makes it the reasoning engine for BMAD's execution infrastructure.
┌─────────────────────────────────────────────────┐
│ PULSE KERNEL │
│ Alpha · Activity Space · Activity │
│ Competency · Work Product · Practice │
│ to_do() / guidance() │
├─────────────────────────────────────────────────┤
│ PRACTICES (extensions) │
│ Scrum · Kanban · XP · Design Thinking │
│ [domain-specific practices] │
├─────────────────────────────────────────────────┤
│ RUNTIME (BMAD-compatible) │
│ Agent · Workflow · Skill (SKILL.md) │
│ Sanctum + PULSE-COMPETENCY.md │
├─────────────────────────────────────────────────┤
│ PULSE-HELP (navigator) │
│ Alpha evaluation · Checkpoint verification │
│ Dynamic dependency graph · Retrograde detection│
└─────────────────────────────────────────────────┘
| LangGraph | CrewAI / AutoGen | BMAD | PULSE | |
|---|---|---|---|---|
| Formal state model | Partial | No | No | Yes — Alphas |
| Knows work is actually done | No | No | No | Yes — checkpoints |
| Adapts plan to state changes | No | No | No | Yes — to_do() |
| Extensions derivable from models | No | No | No | Yes — Practices |
| Methodology included | No | No | Yes | Yes + formal |
| Agent memory | No | No | Yes (Sanctum) | Yes (Sanctum) |
| BMAD-compatible | — | — | Native | Yes |
PULSE defines its own kernel of Alphas for AI agent systems — distinct from Essence's software engineering kernel:
| Alpha | States | Description |
|---|---|---|
| Intent | Identified → Clarified → Validated → Stable | The goal of the effort |
| Context | Empty → Gathered → Structured → Sufficient | Information available to agents |
| Plan | Absent → Drafted → Reviewed → Approved | Work plan |
| Work | Initiated → In Progress → Under Control → Concluded | Execution state |
| Output | Absent → Draft → Sufficient → Accepted | Quality of produced results |
| Team | Undefined → Configured → Operational → Performing | Agent system state |
| Way of Working | Undefined → Adopted → In Use → Working Well | Methods and practices |
These are a starting hypothesis. Defining the minimum viable kernel is one of the first open debates.
Practices are formal, composable domain extensions. Unlike BMAD modules (which are written by hand), PULSE Practices are derived from formal models using PULSE-Builder — a conversational tool that transforms existing methodologies (Scrum, Kanban, XP, Design Thinking) into executable Practices:
- Alphas specific to the methodology
- Activity Spaces with formal entry/completion criteria
- Activities with Approaches and required Competency levels
- Executable SKILL.md files for each Activity
Planned Practices:
pulse-scrum— Sprint, Backlog Item, Sprint Goal Alphaspulse-kanban— Work Item, Flow State, WIP Limit Alphaspulse-xp— User Story, Test, Build Alphaspulse-design-thinking— Problem Statement, Insight, Prototype, Validation Alphas
pulse-framework/
│
├── README.md
│
├── docs/ # conceptual documentation
│ ├── 01_marco_conceptual.md # full debate — how we got here
│ ├── 02_definicion_comercial_interna.md
│ ├── 03_definicion_comercial_clientes.md
│ ├── 04_especificaciones_v01.md
│ ├── 05_resumen_contexto_proyecto.md
│ └── 06_mapa_debates_pendientes.md
│
├── kernel/ # formal kernel definitions
│ ├── alphas/ # Alpha definitions with states + checkpoints
│ ├── activity-spaces/ # Activity Space definitions
│ └── competencies/ # Competency definitions
│
├── practices/ # domain extensions
│ ├── pulse-scrum/
│ ├── pulse-kanban/
│ └── pulse-xp/
│
└── runtime/ # executable implementation
├── pulse-help/ # PULSE-Help navigator
└── skills/ # SKILL.md files for each Activity
- Full conceptual framework
- Initial specifications v0.1
- Alpha kernel definition (minimum viable set)
- PULSE Skill format (SKILL.md extension)
- PULSE Alpha State File format (
.pulse/state.yaml) - Practice composition protocol
- PULSE-Help specification
- PULSE-Help implementation over BMAD infrastructure
- First Practice: PULSE-Scrum
- Real team pilot
- Alpha kernel iteration
- PULSE-Builder: conversational Practice generator
- Practice library for main methodologies
- LangGraph integration as formal orchestration runtime
- Community and Practice marketplace
The following design decisions are open and documented in docs/06_mapa_debates_pendientes.md:
- Minimum viable Alpha kernel — are the 7 proposed Alphas right? Which are redundant?
- Automatic checkpoint verification — LLM evaluation? Scripts? Combination?
- PULSE + LangGraph relationship — should to_do() be implemented over LangGraph?
- State retrograde handling — how does the system respond when an Alpha goes back?
- Boundary with validation systems — where is the line between reasoning and testing?
- Practice distribution mechanism — marketplace? OMG repository? Both?
To be determined.
PULSE is in active conceptual development. The theoretical framework is complete. Technical specifications are in progress. The repository is currently private.
PULSE — because the pulse is the first thing you check to know if a system is alive and progressing.