Agentstration 0.3.0-alpha.1
Agentstration 0.3.0-alpha.1 is a public alpha for local evaluation and contributor feedback. It extends the self-hosted platform with governed source distribution, composable execution, an independently hostable Console, Resource Planning, and additional provider-management capabilities while retaining SQLite and deterministic execution as the zero-external-service defaults. It is not intended for production deployment, and public contracts, AEP contracts, resource schemas, and generated storage schemas remain subject to change during 0.x development.
Highlights
- Sources are now explicitly scoped, immutable, and versioned. Agentstration can administer Source Providers and registry registrations, retain last-known-good registry observations, evaluate trust and compatibility, import exact Source definitions, pin Git-backed Channels to immutable commits, and install Packs from retained catalog provenance. The new Source Registry .NET tool validates publications and computes canonical digests without contacting a running Agentstration instance.
- AEP enrollment and transport now form an authenticated extension boundary. Pairing-code and SharedKeyFile enrollment, administrator-owned scope assignment, credential rotation and revocation, outbound transport controls, and recoverable unenrollment are available through the unified Extensions experience. Provider-specific Compose topologies include their matching Ollama, llama.cpp, or LocalAI extension and inference service without downloading a model implicitly.
- Flows can call child Flows and governed Tools, with bounded nesting, version selection, cancellation, and retry-safe execution. Entry, Trigger, API, MCP, Agent, and Console submissions share one durable root submission path, and causal diagnostics trace root work through child Flow Runs and Tool attempts.
- Agentstration now embeds an authenticated internal MCP server at
/mcp. It dynamically publishes enabled Workspace Tool Definitions and bounded internal Tools throughtools/list;tools/callroutes execution through the same Tool governance and audit pipeline or the durable root Flow boundary, returning operation receipts with the effective immutable Flow version and durable identifiers. The server exposes neither generic Management CRUD nor an unrestricted Flow launcher. - The operations Console now has an independently hostable BFF process shell. Its opaque server-side sessions use instance-bound workload authentication and short-lived, audience-bound API delegations; the all-in-one server remains the executable default. Console Entries can host the same durable interactions as Workplace, and the Conversations view resumes principal-owned work in the Entry's owning Workspace.
- Resource Planning adds Workspace-scoped functional plans, explicit Model Profile, Runtime Profile, and Tool bindings, deterministic reviewable ChangeSets, validation, ordered governed application, durable activity, and Console review.
- Model administration now reconciles typed model observations, persists provider-owned overrides, and resolves effective specifications into compatibility checks and execution. Scoped Parameter and Secret bindings are late-bound for provider discovery and inference.
- A new optional Microsoft Foundry AEP extension integrates existing Foundry project deployments without making Azure a platform dependency. Each Model Provider supplies its project and inference endpoints, authentication mode, and credentials through provider-owned Parameter and Secret bindings. The extension supports deployment discovery, text chat, streaming, and governed Tool calls through the existing Runtime path, with bounded egress, redacted diagnostics, and capability-aware structured output and reasoning.
ApiKey, managed identity, workload identity, and explicit Azure CLI development authentication are supported; Aspire and Compose start the extension only when explicitly enabled. - Management resources now carry explicit instance, tenant, or workspace ownership. Secrets and Vaults follow the same hierarchy with default-deny descendant-use grants. Tool Categories and a dedicated Agent Tools editor organize governed Tools without changing the individual Tool references stored on Agents.
- Startup initialization is coordinated by a durable fenced lease for SQLite and PostgreSQL. The required offline validation is split into fast and integration lanes, and reusable Playwright journeys cover Console and Workplace behavior; live-provider and performance workloads remain opt-in.
Breaking changes
- Management resource persistence now records explicit ownership scopes and uses a new prerelease schema. Existing
0.2.0-alpha.1data directories and databases are not supported for in-place upgrade. Back up anything that must be retained, then start0.3.0-alpha.1with a fresh data directory or empty database and recreate or reapply the required resources. - The
aep.model-providercapability remains version 1.0, but model discovery now returns typed model observations instead of the0.2.0-alpha.1string capability list and metadata bag. No legacy wire adapter is provided; extensions using the previous alpha shape must be updated together with the host. - Authenticated AEP endpoints require extension-specific credentials when authentication is configured. The removed
POST /api/extensions/discoverendpoint has no public replacement; autonomous extensions enroll through PairingCode or SharedKeyFile, while the internal configured-source startup synchronization remains an explicit compatibility option. - Extension enrollment no longer accepts extension-supplied Tenant or Workspace identifiers. An administrator assigns the server-owned target scope after the extension announces itself.
- The root
docker-compose.ymlwas removed anddocker-compose.postgresql.ymlmoved. Use a provider topology underdeploy/compose/and adddeploy/compose/postgresql.ymlas an overlay when PostgreSQL is required.
Upgrade notes
- No supported data migration is provided from
0.2.0-alpha.1. Do not point0.3.0-alpha.1at an existing alpha database. Switching between SQLite and PostgreSQL also does not migrate data. - A fresh published application does not activate the source Development launch profile or create a default credential. Open
/bootstrapon the authoritative server to create the first Platform administrator, Tenant, and Workspace, or configure an explicit declarative Bootstrap profile and secret. - For Compose, choose
deploy/compose/base.yml,ollama.yml,llama-cpp.yml, orlocalai.yml. Adddeploy/compose/postgresql.ymlfor PostgreSQL ordeploy/compose/foundry.ymlfor the optional Foundry extension. Copydeploy/compose/.env.postgresql.examplebefore using the PostgreSQL overlay.
Release artifacts
The GitHub prerelease workflow publishes these assets:
agentstration-server-0.3.0-alpha.1.zip: the framework-dependent authoritative server and built-in operations Console;agentstration-workplace-0.3.0-alpha.1.zip: the framework-dependent standalone end-user Workplace;SHA256SUMS: SHA-256 checksums for the two ZIP archives;container-image.txt: the Docker Hub repository, immutable tag, moving channel tag, target platforms, and pushed manifest digest.
The same tag publishes Agentstration.SourceRegistry.Tool version 0.3.0-alpha.1 to NuGet.org through its separate workflow. That workflow uploads the .nupkg and its own SHA256SUMS as a workflow artifact; the package is not attached to the GitHub prerelease assets listed above.
The server/Console container is built with provenance and SBOM attestations for linux/amd64 and linux/arm64 and published as:
docker.io/agentstration/agentstration:0.3.0-alpha.1
docker.io/agentstration/agentstration:alpha
The immutable version tag is the reproducible release identity. The alpha tag moves to the latest alpha release, and no latest tag is published.
The ZIP applications require the .NET 10 ASP.NET Core Runtime. In separate PowerShell sessions, extract and start the authoritative server and optional Workplace on their default local ports:
# Server and built-in operations Console
Expand-Archive .\agentstration-server-0.3.0-alpha.1.zip -DestinationPath .\agentstration-server-0.3.0-alpha.1
$env:ASPNETCORE_URLS = "http://localhost:5100"
$env:AI__Provider = "Deterministic"
dotnet .\agentstration-server-0.3.0-alpha.1\Agentstration.Web.dll
# Standalone Workplace; the authoritative server must already be available on port 5100
Expand-Archive .\agentstration-workplace-0.3.0-alpha.1.zip -DestinationPath .\agentstration-workplace-0.3.0-alpha.1
$env:ASPNETCORE_URLS = "http://localhost:5180"
dotnet .\agentstration-workplace-0.3.0-alpha.1\Agentstration.Workplace.Web.dll
Run the immutable server image with persistent local state and deterministic execution:
docker run --rm -p 5100:8080 -e AI__Provider=Deterministic -v agentstration-data:/data agentstration/agentstration:0.3.0-alpha.1
The image contains the authoritative server and built-in Console, not the separately hosted Workplace or Console BFF process. It defaults to SQLite under /data; the optional PostgreSQL profile requires an external PostgreSQL 17 service plus the documented provider and connection-string configuration.
Important alpha limitations
- Agentstration remains a modular monolith. The fenced startup lease coordinates initialization but does not make Runtime dispatch, recovery, source refresh, or Quartz scheduling distributed or clustered.
- Flow and Tool execution provides at-least-once behavior and does not claim exactly-once external effects.
- The independently hosted Console uses an in-memory BFF session store by default. Multiple Console replicas require a shared
IBffServerSessionStore, and external OIDC login is not yet implemented. - AEP discovery still emits the dated protocol identifier
2026-09-22; #374 tracks convergence onagentstration.io/v1. This identifier is independent from theaep.model-providercapability version, which remains1.0. - Provider servers, cloud resources, credentials, and models are not installed or downloaded by Agentstration. Deterministic mode is for reproducible evaluation, not real model execution. Foundry live validation remains an explicit opt-in that requires an existing Azure project and deployment.
- Registry refresh and Git Source materialization require network access when invoked, but startup and the required test suites remain offline. The official registry is registered locally without being fetched automatically.
- Pack dependency resolution, signatures, and transactional cross-store reconciliation are not implemented. Public APIs, AEP contracts, resource contracts, Pack and Source formats, and generated schemas may change again before a stable release.
See the current capabilities, configuration guide, Source Registry reference, Foundry integration, and versioning strategy for the implemented boundaries and operational details.