Implemented capabilities and Praxis proposals
Praxis naming: This page documents Praxis, the AIWS workflow engine. Existing
engine/*source paths,/engine/...routes,aiws-engine/*protocol identifiers, and existing script names remain unchanged for compatibility.
Milestone status: M6 is complete for the D-M6-01 supervised Windows 11 x64 / Node 24 / local SQLite developer profile. M8 is now active: its plan is complete; qualification and expanded release/support claims remain open.
This matrix is the first reference for an agent generating application code. Implemented means present in the finite-v1 baseline. M2 source means implemented in the opt-in handoff-v1 source profile, absent from the previously built 0.3.0 binaries. Application-owned means that the host must supply it. Proposed means that no corresponding SDK command or service exists yet; it does not mean the owner-approved design decision is unresolved.
| Capability | Status | Integration rule |
|---|---|---|
| Strict JSON, shared record schemas and decimal accounting | Implemented | Validate at ingress; see wire reference |
| Finite grants, approval fingerprints and dispatch gates | Implemented | Host must authenticate identity and bind policy |
| Deterministic reducer and success assessment | Implemented | No external effects occur during reduction |
| SQLite journal, revision comparison and audit playback | Implemented | One mission per database; replay cost grows with history |
| Coordinator dispatch, UNKNOWN settlement and safe retry | Implemented | Adapter must report truthful external outcomes |
| Recovery segment/epoch and unresolved-attempt report | Implemented | Not a complete worker or target fencing protocol |
| Seven trigger kinds and fixed-interval catch-up | Implemented | Host supplies event ingress and tick scheduling |
| Thirteen node kinds and readiness/completion checks | Implemented | Host supplies task execution and data mapping |
| Input/output JSON Schema checks | Implemented | Restricted schema support; validate artifact bytes separately |
| Control-event traces, metric snapshots and alerts | Implemented | Activity spans and notification routing are host-owned |
| Durable OTLP/HTTP outbox | Implemented | Host must flush it, monitor capacity and manage retention |
| Authentication, human identity and approval inbox | Application-owned | Do not trust an actor string in a command |
| Real test execution and acceptance evidence | Application-owned | SDK checks records, not the truth of an external test report |
| External idempotency, cancellation and read-back | Application-owned | Do not promise exactly-once effects |
| Cron/calendar/DST scheduling and live background workers | Application-owned | Current schedule is UTC fixed interval |
| Nested work-order limits and a protected handoff reserve | M3 source | Separate shared LimitStore; all external dispatch must pass ledger and existing host gates |
| Resumable holds at loop/resource exhaustion | M2/M3 source | Handoff holds plus nested admission gates; finite-v1 LOOP remains terminal FAILED |
| Atomic handoff manifests, delivery claims and acknowledgements | M2 source | Opt-in HandoffStore and authenticated host coordinator |
| Content-addressed artifacts and retention checks | M2 source | Native FileArtifacts; host owns backups, retention and cleanup |
| Automatic restart policy and task-aware pause orchestration | Proposed | Current records do not start/restart processes |
| Dynamic graph mutation, task injection and agent replacement | Proposed | Current attached graph is fixed |
| Long-history compaction and inspection | Implemented in local engine source | Lossless segments, indexed pages and resumable verification; see replay limits. Native 0.3.0 SDK parser limits remain unchanged |
| Months-long Praxis qualification | Pending | Requires retention, platform and measured capacity evidence |
| Protocol binding abstraction for MCP, A2A and AG-UI | M9.1 complete | Common manifest/catalog/observation boundary is verified; protocol compatibility still requires protocol-specific conformance |
| MCP 2026-07-28 outbound integration | M9.2 complete for synchronous profile | Official v2.2.0 client/server conformance passed for tools/resources/prompts, host auth, timeout/cancel UNKNOWN handling and material capability pinning; Tasks/restartable remote handles are M9.3 |
| MCP Tasks durability/recovery | M9.3 complete | Durable remote-task mapping, persisted restart handoff, polling, revision-bound approved input, cancellation, retry fencing and UNKNOWN reconciliation are verified against pinned official @modelcontextprotocol/ext-tasks conformance |
| A2A 1.0 outbound client | M9.4 complete | Durable task identity, fresh Agent Card/skill material pinning, endpoint/time fencing, polling/resubscription and pinned official @a2a-js/sdk@1.3.0 HTTP+JSON conformance are verified |
| A2A 1.0 Praxis server / Agent Card | M9.5 complete | Authenticated/authorized admission, durable inbound remote↔local identity, official AgentExecutor bridge, status/artifact streaming and terminal-task immutability are verified; A2A events never grant Praxis authority |
| AG-UI 1.0 event projection | M9.6 complete | Projection-only run/step/message/tool/state/activity/subagent events validate against pinned official @ag-ui/core@1.0.0; no Praxis mutation or approval/control ingress is introduced |
| AG-UI authenticated human control | M9.7 complete | Standard interrupt/resume maps to the existing authenticated, material-bound, durable Praxis control API; exact retry/receipt recovery and official AG-UI 1.0 schemas are verified |
| Durable cross-protocol registry and observability | M9.8 complete | Immutable binding revisions, separate local/remote identity, evidence correlation, stale-result fencing and allowlisted hashed-identity telemetry are verified |
| Cross-protocol compatibility campaign | M9.9 complete | MCP 2026-07-28 + Tasks, A2A 1.0 and AG-UI 1.0 passed together across 4 profiles, 16 required scenarios and 16 executable checks |
| Cross-language protocol correlation helper | M9.10 complete | TypeScript/Rust/Python source records correlate AIWS/Praxis identity with exact binding revision/remote identity and require authoritative: false; not present in older 0.3.0 binary archives |
| Recovery on another machine | Outside agreed Praxis scope | Do not infer distributed failover support |
A useful current application boundary
Section titled “A useful current application boundary”Applications can use the libraries now to govern an adapter-driven workflow, persist its control history, retain uncertainty, inspect outcomes and emit telemetry. They still need a host that invokes the coordinator and supplies the trusted services above. The tutorial demonstrates this boundary without inventing scheduler or handoff APIs.
No npm, crates.io or PyPI publication is implied by the package names. Download the supplied packages or use the source workspace. SDK 0.3.0 and proposed standard edition 0.4 are different version numbers with different purposes.
M2 source additions
Section titled “M2 source additions”All three SDKs implement immutable handoffs, per-consumer receipt claims, atomic admission, resumable RUN/BRANCH holds, pinned join inputs, artifact verification, deterministic reports, metric counts and a correlated durable notification outbox. See handoffs for equivalent examples and exact API boundaries. Work order = mission is an accepted identity. Full scheduling, worker lifecycle and dynamic graph changes remain Praxis work.
M3 source additions
Section titled “M3 source additions”All three SDKs provide the opt-in aiws-limits/1 ledger: hierarchical cost, active-time, elapsed-time and attempt accounting; protected handoff allowance; ancestor/dependency admission gates; durable reservations, stop/settlement evidence and human-only adjustment. Read budgets for equivalent programs and required host ordering. No cross-database atomic commit, external cancellation service or automatic import of historical running work is claimed. M3 APIs are source additions, absent from the older 0.3.0 binary downloads.
M5 Praxis source boundary
Section titled “M5 Praxis source boundary”The separate TypeScript engine/ package now has executable SQLite, scheduler, dispatch, worker, validation and control primitives. Persistence and recovery tests documents the verified storage slice and its limits. A composed local coding workflow now executes approval through acceptance, including bounded correction and interrupted recovery. M5 remains in progress: full wire/authentication integration, CLI/web controls and conformance closure are not complete. Engine source APIs are not exports of the three released SDK 0.3.0 packages.
The M5 local control profile now provides authenticated HTTPS, CLI and web decisions for the composed workflow. Production enrollment/provider integrations, the complete command catalog, paged history and release qualification remain open.
Protocol interoperability
Section titled “Protocol interoperability”M9 is complete as the scoped protocol-interoperability feature track; M8 remains the independent qualification track. The common Praxis source contract represents version-pinned MCP, A2A and AG-UI bindings while keeping external observations non-authoritative. MCP synchronous/Tasks, A2A 1.0 client/server and AG-UI 1.0 event-projection profiles are verified against pinned official packages. AG-UI authenticated human-control ingress is verified in M9.7; M9.8 verifies a durable cross-protocol registry and privacy-preserving telemetry projection in engine source; M9.9 verifies the executable pinned cross-protocol campaign: all 4 advertised profiles, all 16 required scenarios and all 16 executable checks passed. M9.10 completes the cross-language correlation helpers, runnable examples, operator/recovery documentation, exact compatibility matrix and four scalable SVG architecture maps. Read Praxis protocol interoperability and the repository docs/M9-BUILD-PLAN.md before generating integration code.
Dynamic client controls
Section titled “Dynamic client controls”M7 slice 8 adds native TypeScript/Rust/Python contracts and verified HTTPS clients, protected-input CLI and reviewed web controls. All eleven dynamic decisions share the existing authoritative Praxis semantics. See native dynamic controls. Use current GitHub source; baseline downloadable SDK packages are unchanged.