18 — Roadmap¶
The Aetherium Engine is functional and in active development. This section is the honest accounting an evaluator actually wants: what the Engine does not do yet, and where it is likely headed. No dates appear anywhere below, because none are promised — what follows is a set of identified improvements, not committed deliverables.
It comes in two parts, and they carry different weight. The first is known limitations being addressed: concrete, code-traceable gaps, each one already documented elsewhere in these pages and cross-linked here so you can read the current state for yourself. The second is directions under consideration: looser, clearly speculative, and deliberately kept short. For someone deciding whether to invest hardware and time in a platform, a candid limitations list earns more trust than a feature-promise list — so the limitations come first and in detail, and the speculative part stays explicitly speculative.
To put the gaps in proportion, the parts an evaluator usually probes first are built and documented. The local-first, single-host deployment path is real and has been run end to end (§14 — Deployment); the three-layer permission model gates every in-process tool, and the egress and credential-scanning checks wrap every outbound call (§07 — MCP Architecture); the four topologies, the supervisor orchestration loop, and the MCP tool surface are all in place (§06 — Key Services); a benchmark harness exercises whether a given model actually drives tools end to end (§11 — Benchmarking). What follows is the smaller set of places where the Engine knowingly stops short — which is exactly the set worth naming for someone weighing maturity.
One framing matters before the list. None of these is a defect in the sense of something broken. Each is a boundary the Engine draws on purpose today — an open trade-off, several of them recorded with their reasoning in §17 — Architecture Decisions — paired with a known direction for tightening it later. Read them not as "what's unfinished" but as "what the Engine chose not to do yet, and what would change that."
Known limitations being addressed¶
Security¶
The two security gaps are the ones an evaluator should weigh most heavily, because both shift work onto the operator that a more mature platform would absorb.
Orchestrator API authentication. This is the largest single item. The orchestrator API carries no built-in authentication — the build endpoints POST /api/orchestrator/run and /api/orchestrator/run-from-template trust whatever reaches them, and network isolation is the only boundary. That is deliberate, not an oversight: identity is pushed to the edge, where a reverse proxy, an API gateway, or a private network enforces it (ADR 3 in §17). But because every agent can run shells and write files inside its container, an unauthenticated build endpoint becomes an arbitrary-code-execution surface the moment it is exposed — which is why §13 — Integrations, §14 — Deployment, and §15 — Operations all carry the same warning never to put it on the open internet. The likely direction is built-in authentication on the API itself — bearer tokens, mTLS, or a gateway integration — so identity stops being entirely the deployment's responsibility. It is the Engine's most consequential open trade-off, and the one most clearly on the table.
Audit-log retention. Every gated tool call is written to the ToolSecurityAuditEntries table by ToolSecurityAuditService, and nothing prunes it. There is no retention key, no background sweep, and — unlike most project data — the rows survive even when their project is deleted (§15 — Operations covers the manual prune; §09 — Configuration flags the missing key). On a continuously running Engine this table is the single most likely thing to fill the disk, and today pruning it is the operator's job, done with a scheduled delete. The likely direction is a retention key and an automatic sweep, so the audit trail ages out the way container snapshots and workspace archives already do.
Configuration¶
The configuration gap is narrower, but it is the kind that sends an operator hunting for a knob that does not exist.
The RAG relevance threshold was hardcoded — resolved. search_knowledge used to discard anything scoring below a bare 0.05 literal, and the global-fallback cascade carried a second hardcoded 0.5. Since 2026-10-10 the floor is the ChromaDb:ScoreFloor key (default 0.525, on cosine similarity, which is where 0.05 sat on the old L2 score), applied by the store, the tool and injection alike; the fallback cascade and its threshold are gone (§09 — Configuration).
Build and deployment¶
Two items here are about smoothing rough edges rather than closing risk — but both are places where the Engine currently asks a person to know something the tooling should handle.
The fresh-clone build prerequisite — resolved. A fresh Linux clone used to fail its first build with a glob-expansion error until bin/ and obj/ existed, because MSBuild handed the compiler a literal **/*.razor when those directories were missing. Retiring the Razor client removed the glob along with the files, and a clean clone now builds with no preparatory step. The planned MSBuild target is no longer needed.
The inert container pool — resolved. ContainerPoolService read like it maintained a warm pool of pre-started containers, but the warm-up routine was never called and the whole path sat behind an agent-isolation flag that shipped off. The fork was activate or remove, and on 2026-09-07 it was removed: the pool service, the per-agent isolation path, and the Container_DefaultPoolSize, Container_PoolIdleTimeoutMinutes and Feature_AgentIsolation settings are gone. Every agent on a project shares that project's container, which is what the running system always did.
Read together¶
The five share a shape worth naming. None of them compromises the local-first guarantee or the container sandbox — the boundaries that define what the Engine is; they sit a layer above that, in what the operator and the developer have to handle by hand. Two (authentication, audit retention) hand the operator a responsibility that automation will eventually absorb. One (the RAG thresholds) was a missing knob, and it is now a key. Two (the fresh-clone prerequisite, the container pool) were rough edges in the developer and runtime paths, and both are now resolved. And every one has a documented mitigation you can apply today — the scheduled prune, the one-time mkdir, the edge proxy. That is the tell: each is listed here precisely because a workaround stands in for a fix that has not landed, and the direction is to retire the workaround.
Directions under consideration¶
Beyond those concrete gaps, a few broader directions are under consideration — and these are genuinely speculative, with no design committed and nothing promised. Deeper observability is one: the Engine logs to standard output with no ambient correlation ID tagging a single run end to end (§15 — Operations), and richer tracing would make a multi-agent build easier to follow under load. Broader inference-provider support is another natural line, since the Engine already speaks the OpenAI-compatible API and is not structurally bound to one backend (§13 — Integrations). Richer template-authoring tooling is a third, given that the Sequential and Roundtable topologies ship without a ready-made template today. Treat all three as directions rather than plans; they are noted here only so the maturity picture is complete, not because a date or a design sits behind any of them. Anything more specific would be guessing at a delivery the Engine has not committed to — and for an evaluator, a guess dressed as a plan is worse than honest silence.
Where to go next¶
- §17 — Architecture Decisions — the reasoning behind the trade-offs these limitations sit on, the authentication boundary chief among them.
- §15 — Operations — operating around the current limitations: pruning the audit table, the real container-pool behavior, reading the logs without correlation IDs.
- §09 — Configuration — the configuration gaps named above, and the keys that do exist.