Introducing ASE 1.0

Today we are releasing ASE 1.0 — Agentic Solution Engineering — a self-hosted control plane for defining, launching, supervising, governing, and reporting on multi-agent engineering work.

ASE is built for the engineering and platform leaders who have watched agents move from demo to production over the last eighteen months and asked the obvious next question: how do we run this with the same operational seriousness as the rest of our regulated estate?

This release is our answer.

We call it solution engineering rather than software engineering deliberately. Code was the first domain we governed this way, and it remains the deepest — but the loop that makes agentic code delivery defensible turns out to be the same loop that makes agentic infrastructure work, regulated document generation, and any other consequential planning defensible. Define the problem, decompose it, gate the risky steps, and keep the evidence. The domain is a configuration detail.

The problem we built ASE to solve

Coding agents are now genuinely useful. They plan work, write code, run validations, open pull requests, and increasingly cooperate across long-running tasks. In a regulated environment, that capability creates a new operational gap.

A single agent on a developer’s laptop is a productivity tool. A fleet of agents writing production code on behalf of an organization is an operational workflow — one that crosses identity, access, change control, and compliance boundaries. Ad-hoc logging, custom shell scripts, and trust are not enough to manage this transition.

That works until an auditor, a regulator, or an incident reviewer asks the questions our customers cannot afford to answer with a shrug:

• Which version of the prompt, model catalog, and harness policy executed this change?
• Who approved the execution, and against which versioned problem definition?
• What immutable evidence proves that the agent constellation did not exceed its scope?
• How do we audit, reproduce, or revert what an agent did three weeks ago?
• Which Keycloak identity and credential authority did the agent act under?

ASE exists so those questions have crisp, defensible answers.

Domains, not forks

A solution domain in ASE is a vertical pack — a versioned set of definitions, gates, and evidence rules that a run is launched against. 1.0 ships packs for greenfield, feature, and legacy-parity software work, for platform engineering and infrastructure-as-code, and for govcon document generation (Program Protection Plans and Security Classification Guides) alongside CMMC Level 1 & 2 self-assessment.

Because a pack is configuration rather than code, the surface generalizes further than the enterprise roadmap suggests. We plan multi-day backcountry routes with it — permits and quotas as hard constraints, water carries and resupply as dependencies, weather windows and bail-out points as gates. It is a genuinely useful application, and it is also the cleanest proof we have that the engine does not care what the solution is made of.

How ASE fits an agentic stack

ASE is deliberately not a monolith. It coordinates a federated stack of specialized services through clean authority boundaries:

• Planning Boundary (Bo by default) — extracts code intelligence, maps dependencies, and generates deterministic work decompositions and validation plans.
• Live Coordination (via CLAiR) — manages claim arbitration, blackboard state, and transient runtime leases using the Agentic Code Orchestration Protocol (ACOP).
• CLAiR Graph (powered by BogDB) — serves as the queryable read model for durable, graph-shaped evidence and run history.
• Identity Authority (via Keycloak) — enforces secure OIDC token authority, MFA, passkeys, and role-based permissions.
• Agent Harnesses — executes individual agent processes under session-scoped credentials with environment-isolated configurations.
• ASE Control Plane — owns the human- and product-facing interface, managing definitions, launch approvals, live dashboards, compliance reports, and audit trails.

This boundary matters. It means ASE does not compete with the agent frameworks or coordination layers our customers already run. It governs them.

Who ASE 1.0 is for

ASE 1.0 is designed for engineering organizations where agentic work is no longer experimental and the cost of an ungoverned run is high. That includes:

• Regulated industries — financial services, healthcare, public sector, critical infrastructure — where auditable evidence is a precondition for adoption.
• Platform and developer-infrastructure teams responsible for how the rest of the company uses coding agents safely.
• Organizations with data-residency or sovereignty requirements that rule out hosted control planes by default.

If your team is running agentic coding through shared scripts and personal credentials today, ASE is the operational layer that lets you scale it without inheriting a compliance problem.

What’s next

The 1.0 milestone closes the foundation, identity, definitions, launch, supervision, and audit-export loop. Near-term work is focused on deeper compliance reporting, richer constellation supervision, and broader first-class harness support.