another-agentic-platform

A Kubernetes-native platform for running durable, versioned, independently addressable AI agent services on disposable compute.

Status: design, and the first code of the v0 operator. Formerly the lightbridge-agents draft.

The first operator (v0: adam-rs agents from AgentService and AgentConfig on native Kubernetes) is specified in §59a. Slices S1 to S9 are built: the Cargo workspace, the CRD types, the CRDs and the examples (S1); the pure core that validates and resolves them, with parity goldens against the adam-rs chart (S2); the provider traits and their conformance testkit (S3); the RuntimeProvider on native Kubernetes (S4: proven against a fake API server, and against a real one only once the runtime-kubernetes CI job has run); the controllers, the referenced-Secret store and operator run (S5: proven against a fake API server and against a bare kube-apiserver; the pods half, in kind, is unverified until the operator-e2e CI job has run); the operator-owned CloudNativePG store (S6: proven against a fake API server, and against a real CloudNativePG only once the store-cnpg CI job has run); the agent registry the operator serves, with its document read by the system's own reader, vendored (S7: proven against a fake directory and against a bare kube-apiserver; a pod reading it, in kind, is unverified until the operator-e2e CI job has run); the operator's image, its Helm chart and the CRDs chart, and the workflow that builds, pushes and bumps the image (S8: the operator-image run on main for e3d164c built and smoke-tested the image and pushed sha-e3d164c, which f9168e6 bumped into the chart; an anonymous manifest request for that tag answers 200; verified 2026-10-15, run 37307542288 and the registry; installed from the registry on a real cluster by Argo CD, S10, it is unverified), and the kind end-to-end of the coder (S9: the operator, from its chart, runs the real adam-rs coder image up to its startup checks, with no model and no GitHub; its operator-coder-e2e job passed in that run, verified 2026-10-15). Of the admin dashboard (§60a) slices D1 to D6, D7a, D7b1, D7b2, D13, D15a, D15b, D15c and D15d are built. D1: the CRDs gain access.audience, the kinds ModelEndpoint and ToolProvider (a v0 subset), the exclusive endpointRef and providerRef fields and an optional environment.image, proven by tests and by hand against a bare kube-apiserver v1.35.8 (its kind job is unverified until CI has run it). D2: the operator resolves them, so a config that references an endpoint or a tool provider, or names no image, runs what the same content written inline runs; a missing object blocks the agent, naming it; the controller watches both kinds; and operator run takes a default agent image, a value of the chart with a pin of its own (proven by tests and by hand against a bare kube-apiserver; the Role's new verbs under real RBAC are unverified until the kind jobs have run). D3: the registry publishes the audience of a service as the optional item attribute audience (a sorted set; none and [] are no attribute), and the contract agent-registry-v1 gains it with the consumer's rule and stays v1; the system's reader as it was before the attribute (vendored then) read such a document with nothing skipped, and the copy re-vendored since, at the system's D8 commit, reads the audiences, and the audience still reaches no pod (proven by tests and, for the registry case, by hand against a bare kube-apiserver; the kind job is unverified until CI has run it; the system's enforcement is D8). D4: the dashboard's forms and the two ports its Platform API is generic over, AgentObjects and Authenticator, each with a Memory implementation and a conformance macro, and the permission constants of aap-api: aap-forms turns an agent (a coder or a folder agent), a model endpoint and a tool server to and from the custom resources with the deployment's defaults filled in, names every validation error by its form field, says for any object whether a form can represent it or it is YAML only, and exports YAML through allow-lists, with the strings a YAML 1.1 reader misreads quoted; a form names a secret by reference only, and an agent's own image needs a tag or digest and an allowed registry (proven by tests, including properties over arbitrary forms, each broken on purpose; what needs an API server is D5 and an issuer D6). D5: AgentObjects on the API server, aap-objects-kubernetes: server-side apply under agents.vymalo.com/dashboard, force off, with both applies dry-run (and the resourceVersion and uid read named in them) before either is real, so a stale token, a field another manager owns or a rule of the CRDs on either body is refused with nothing changed (the one window left, between the two real applies, is told by what changed and logged: a move of the service's version alone, which the operator causes, is repeated once and succeeds, anything else leaves the config written and answers, for the most part, 412); a delete waits at most 5 s for the operator's finalizer and deletes the config last, because the operator reads it to honour deletionPolicy (a config deleted with the service could lose the data of a person who had just saved Retain), and what it leaves is an orphan config that a delete of its name removes; a GitOps object is never written or deleted; the offered keys are read from labelled external-secrets.io/v1 ExternalSecrets and no Secret is read; the Role it needs is create, delete, get, list, patch on the four kinds and list on externalsecrets, held equal to its calls by a test. Proven by tests on a fake API server that copies the real behaviour, and by the conformance suite on a bare kube-apiserver v1.35.8 (56 cases on 2026-10-16, as an administrator and as a user that holds only that Role; the operator's finalizers are played by the test harness), each property broken on purpose; what a resourceVersion does in an apply is verified 2026-10-16 there; the objects-kubernetes CI job is unverified until it has run. D6: the Authenticator of the Platform API, aap-auth-oidc, a bearer JWT checked against the keys of an OIDC issuer as the system's orchestrator checks one, without DPoP (a token that carries cnf is accepted as a plain bearer, which is a question for the owner): RS256, RS384, ES256 and EdDSA only, iss, one of the configured audiences in aud, exp and sub required, nbf honoured, 60 s of leeway, the values of the configured roles claim as the person's permissions (a bad roles claim never refuses a token); a key cache that refreshes at 10 minutes, refetches on an unknown kid at most once in 30 s and fails closed an hour after it can no longer refresh; no error, log or source holds a token, a claim or a kid; an issuer on a local port in its testkit. Proven by tests over real HTTP, aap_ports::authenticator_conformance! among them, each check broken on purpose; a real Keycloak's keys and its roles claim are unverified until the realm is tried. D7a: the Platform API's router and its binary, aap-platform-api and aap-api-server (binary api): every route of §60a under /v1, built from one table of routes and permissions that one middleware reads (a route outside it is a 500); problem details (RFC 9457) with the form field of every 422; conditional writes (If-None-Match: * creates, If-Match replaces and deletes, strong ETags, 428 otherwise); platform:secrets.pick asked of a write whose form names a secret key; a change that would break the agents that name a model or a tool server refused (409); CORS for exact origins only; a log with no token, body or secret key; the binary reads one YAML file (unknown keys refused, validated at load) and drains on SIGTERM. Proven by tests on the Memory ports, over a real signed token and on a real socket, the route-by-permission matrix among them, each check broken on purpose (33); the binary has not run against a real API server or a real issuer: D7b2, the kind end-to-end through the API, is next. D7b1: the API's image (docker/api), its build, smoke test, push and tag bump in operator-image.yml (one workflow for both images and one bump commit, so two pushes to main cannot race), and the chart's api component in deploy/operator, off by default: a Deployment, a Service, its own service account and a Role that is exactly the one the objects crate is tested under (held equal by a check; no Secrets), a ConfigMap rendered from the values, a NetworkPolicy, and an optional Ingress whose annotations are where the edge's per-token rate limit is attached (the API implements none); the chart refuses what the binary would refuse, and CI runs the image's api --check on the file it renders. Proven by render-check.sh (194 checks), kubeconform over six renders, the release binary's --check on the rendered files and the workflow's smoke steps run against it; the image build and every CI job of the slice are unverified until CI has run them (no container daemon runs where it was written). D7b2: the kind end-to-end through the deployed API (api-e2e.sh, the job api-e2e of operator-image.yml, which the push waits for): the operator chart with the API on, the testkit's issuer as a program on the runner, and a folder agent created through the API, made Ready by the operator, listed, read, exported, replaced and deleted with its ETags, with no secret value in any answer or log; the job passed on its first run (run 38896792093, verified 2026-10-16 in its log); after review (2026-10-16) the script refuses a context that is not kind-*, works in a namespace of its own, undoes only what it made, handles an orphan config after a 202 and requires the NetworkPolicy to refuse the other pod: those changes passed in CI too (run 38970194294, the push to main at 2ca4454, verified 2026-10-17 with gh api and in the job's log: a 204 on the delete, the other pod refused with status 000); the hardening that D13's review gave chain-e2e.sh (printf for bodies, the logs read by a kubectl logs that succeeded and holding a line of their own component, redacted diagnostics, the context pinned for helm, panicked at) was then ported to api-e2e.sh: that port is unverified until CI has run it (walked under dash against a fake kubectl, not on a cluster). D13: the kind end-to-end of the whole chain (chain-e2e.sh, the job chain-e2e of operator-image.yml, which the push does not wait for): the API makes a coder with an audience, the operator runs it and lists it in its registry, and the system's orchestrator, a published image pinned by tag and digest, lists it for the person who holds the role (alice), not for another (bob: [], the registry ok), for the administrator (the pinned system's rule, against the registry contract's: an open question for the owner, asserted as built) and not for the one who holds only the audience's value (carol: 403 no_access), then the coder is deleted and the listing empties, with no secret value or token in any answer or log; the stand-in's card is now a valid A2A 1.0 card; verified 2026-10-17: the two pins by anonymous manifest requests, and the configuration and the tokens accepted by the orchestrator built at the pinned commit, the whole script walked under dash against it and the real router, registry and issuer with a fake kubectl and helm; the job passed on its first run (run 38994193619 at 4929e3c, verified 2026-10-17 in its log: the kubelet pulled both pins, the orchestrator's pod became ready, the policies admitted it, the operator's real Ready and Listed, the four people's answers, the delete, no secret in any log); the changes of its review of the same day (the logs and the empty registry checked so that they cannot pass on nothing, the diagnostics filtered, the context pinned for helm, Postgres's probe over TCP, the digest on one line) passed in CI too (run 38996503582 at the PR head 8d45dab, verified 2026-10-17 with gh api and in the job's log: each of the three logs read by a kubectl logs that succeeded and holding a line of its own component). Slice D15a (2026-10-26) is the half of D15 that needs no cluster: the operator sets up run pods for a coder (adam-rs #131, 3f714d0) when its AgentConfig sets coder.runPods.sizeClass: the pod template its workers read, an account with its token, a quota scoped to a priority class, a network policy and the binding of the account to a Role, with the chart's runPods and runPodClasses (off by default, and then not a trace of them in any render: the four goldens are what they were), one admission policy for every agent whose values the operator writes into a ConfigMap per agent, a Role for the operator that holds bind on the one Role of run pods and no right to make a pod or exec, agent.runPodSizeClass in the coder form and runPodSizeClasses in GET /v1/info; proven by parity goldens at adam-rs 3f714d0 (the template, and the quota, network policy, binding, Role, PriorityClass and admission policy with the parameters substituted), render-check.sh, the policy's 25 refusals asked of a bare kube-apiserver v1.35.8 (deploy/operator/tests/run-pods-admission.sh) and a mutation of each guarantee; the kind end-to-end is D15b (next), and the decisions of D15a for the owner to confirm (the operator's bind, the policy that fails open for an account whose parameters are deleted, the quota shared by the agents of a namespace, a GitHub App coder with no run pods not refused) are in §60a and P-020. Slice D15b (2026-10-27) is that kind end-to-end: deploy/operator/tests/e2e/run-pods-e2e.sh and the job run-pods-e2e of operator-image.yml (it runs the operator image that passed its smoke test; push does not need it, an owner decision), which installs the operator chart in kind twice, first without run pods and then with them (the upgrade), and runs the real adam-rs coder, pinned by tag and digest in run-pods.yaml and nowhere else (sha-3f714d0 when it was built, sha-7598255 since D15c; defaultAgentImage is not moved), as a token coder with no run pods, which must be as it was after the upgrade, and a GitHub App coder with coder.runPods, on a scripted model that the coder's own image runs. It shows the operator's objects for the one and none for the other, run-pods-admission.sh run in the cluster as the agent's account, kubectl auth can-i --as against both Roles, a command run in a run pod made from the operator's template that sees only its own run (two runs, then one in a repository with a mirror and a worktree), the quota counting two pods and refusing a third while the coder waits for a slot, the network policy, a deleted service taking everything with it, run pods included, and no secret in any answer or log (render-check.sh holds its fixtures, each new check broken on purpose; the model has node --test tests of its own). Verified 2026-10-27: the coder's pin by an anonymous manifest request to ghcr.io, and the whole script walked under dash against a bare kube-apiserver v1.35.8 (RBAC, quota and admission policy), the real operator running as its own service account, the real coder at adam-rs main (the code of 3f714d0) and a Postgres, with a stand-in for the kubelet, its main assertions broken on purpose and failing where they should. The job has run green (run 40435825771 at 0b5a67f, job run-pods-e2e, verified 2026-10-27 with gh run view), after its first full run (40432460348) found a fault of the provider in step 9 (an account deleted while a workload still named it), fixed. Its seven decisions for the owner (it does not gate push; the pin is the fixture's own; the model is a script of the coder's image; the network check fails without an enforcing plugin; the quota probe is an administrator's; a made-up App; copied helpers) are in §60a. Slice D15c (2026-10-27) makes the operator close the network of a run pod as adam-rs did in its coder chart (its ADR 0042, ff10395 and 7598255): the run pods' NetworkPolicy is deny by default (DNS, the egress proxy's pods on 3128, extraEgress; no rule names an address range), and for each agent with run pods the operator makes the egress proxy, adam-egress from the agent's own coder image (a Deployment, Service, ServiceAccount, PodDisruptionBudget, NetworkPolicy <svc>-egress and a ConfigMap <svc>-egress-allow), and the template carries HTTPS_PROXY, HTTP_PROXY and NO_PROXY. The allow-list is the deployment's (runPods.egressProxy.{allow, extraAllow, extraNoProxy, replicas, ports, resources} of the operator chart, read from RUN_PODS_FILE, with the coder chart's checks; runPods.networkPolicy.enabled is gone); the proxy is applied before the policy that names it and cleared before it, the run pods' policy being the last policy to go; the operator's Role does not change. Proven by the parity goldens moved to adam-rs 7598255 (the env contract of a coder with run pods off did not move; the template and the proxy's six objects compared object by object in four cases), tests on the fake API server (apply, update, clear, order, a foreign object of a name blocking), render-check.sh (each new check broken on purpose in a copy of the tree) and the jq programs of the new end-to-end checks run against the operator's own objects; the coder's pin moved to sha-7598255 (verified 2026-10-27 at ghcr.io: a Docker v2 manifest, revision label 7598255, a layer that copies adam-egress). D15c's job has run green (verified 2026-10-27, run 40484065490, job run-pods-e2e 122121514621: step 7, the network checks, passed after a fix to step 5's mount expectation; step 7 asserts that a kubelet starts the proxy from the pin, that kindnet drops the direct connections and that curl and npm go through the proxy). The ten decisions of D15c for the owner (the allow-list is the deployment's; an agent image without adam-egress, which defaultAgentImage is, is documented and not refused; the proxy is no workload of the service; ...) are in §60a and P-021. Slice D15d (2026-10-27) puts the coder's own git where no secret is readable, as adam-rs did in its coder chart (issue #118; its ADR 0041 open decision 6, 05cda7f and 581aeed): with run pods the coder's pod gets a git-sandbox native sidecar (the agent's own image, adam-git-sandbox; it mounts the work volume at the coder's path, its socket's emptyDir and an in-memory /tmp of its own and nothing else: no Secret, no variable from a Secret, no token, a read-only root file system, a process namespace of its own), the account's token as a projected volume of the coder container alone (the pod's automountServiceAccountToken is false) and GIT_SANDBOX_SOCKET. aap-ports gains VolumeSource::{Scratch, AccountToken} (the second only the agent container may mount) and Container::read_only_root_filesystem; the settings gain runPods.gitSandbox.{resources, tmpSize, maxCommands} of the operator chart (the coder chart's defaults and checks, a memory limit required, no switch); the operator's Role does not change. Proven by the parity goldens moved to adam-rs 581aeed (the three cases without run pods differ by the revision alone), one function asking "does the sandbox hold what the coder holds" of the chart's golden and of the operator's spec, the real render compared with the golden, render-check.sh (each new check broken on purpose in a copy of the tree), the vendored vector, and the jq programs of the new end-to-end step 4b run against a pod made from the operator's own render (passing, and failing under seventeen of seventeen mutations); the coder's pin moved to sha-581aeed (verified 2026-10-27 at ghcr.io: a Docker v2 manifest, revision label 581aeed, a layer that copies adam-git-sandbox and adam-git). D15d's job has run green (run 40520862547, job run-pods-e2e 122249371008, at b8290bf, verified 2026-10-27 in its log): a kubelet started the sidecar and the coder after it, the sidecar held no token, key, Secret or secret variable and saw none of the coder's processes while the coder container had them (the control), a commit through the socket worked, a repository whose configuration names a filter and an fsmonitor ran them in the sandbox and they read none of the five secrets while plain git in the coder container read all five, the coder's own git worktree for run C was in the sandbox's log, and runs A, B and C behaved as before with their git in another container. The eight decisions of D15d for the owner (no switch; an agent image without adam-git-sandbox, which defaultAgentImage is, is documented and not refused, and its coder never becomes ready; the pod never automounts a token; ...) are in §60a and P-022. Nothing else of the architecture is built.

An agent is a stable logical service — not a Pod, a model, a workspace or a process. It has a stable identity, immutable revisions selected through release channels, explicitly enabled protocol surfaces (A2A, MCP, Responses), reusable tools and environments, and compute that exists only while a lease needs it.

flowchart TB
    Config[AgentConfig] -->|publish| Revision[AgentRevision]
    Service[AgentService] -->|production / staging| Revision
    Run[AgentRun] --> Service
    Run --> Revision
    Run --> Lease[AgentLease]
    Lease --> Runtime[RuntimeProvider]
    Runtime --> Agent[Agent Runtime]
    Workflow[WorkflowProvider] --> Run

Loading

Documents

Document	What it covers
Architecture	The full design in 12 topic files: overview, domain model, interfaces, workflows, runtime, environments & storage, tools, security, operations, control plane & CRDs, decisions, summary
MVP	The v0 cut (scenarios A–C, plus D for free) and build order
Release-channels A2A extension	How any A2A client discovers and selects an agent's channels/revisions
Agent registry	How any client lists the fleet's A2A agents: a linkset of agent cards

Workspace

One Cargo workspace (§59a, "Workspace layout"); crates are prefixed aap-. Built so far:

Path	What
crates/api	aap-api: the AgentService, AgentConfig, ModelEndpoint and ToolProvider types, their CEL rules, crds(), and the dashboard's permissions as constants
crates/ports	aap-ports: the traits RuntimeProvider, StoreProvisioner and AgentDirectory, and for the Platform API AgentObjects and Authenticator, their neutral types (RuntimeSpec, EnvValue, SecretRef, RuntimeStatus, …), and with the feature testkit the conformance macros and Memory implementations
crates/forms	aap-forms: the dashboard's agent (coder or folder agent), model endpoint and tool server forms to and from the custom resources, with the deployment's defaults; a secret is a reference and no type holds a value; validation with a form field on every error; YAML only for an object a form cannot say; the YAML export
crates/domain	aap-domain: pure validate and resolve into a RuntimeSpec with a sha256 digest; the env contract of adam-coder and adam-agent lives only here, held equal to the adam-rs chart by parity goldens
crates/runtime-kubernetes	aap-runtime-kubernetes: RuntimeProvider on native Kubernetes: a RuntimeSpec into StatefulSet or Deployment, Service, NetworkPolicy, ConfigMaps and claims by server-side apply, the adoption guard, RuntimeStatus from pods, deletionPolicy, watch(); golden YAML of the examples, a fake API server, and the conformance suite against a real cluster
crates/store-secret	aap-store-secret: StoreProvisioner for a referenced Secret: it reports the reference and never reads a Secret (the operator has no RBAC on Secrets)
crates/store-cnpg	aap-store-cnpg: StoreProvisioner for an operator-owned CloudNativePG Cluster <service>-db: server-side apply through the dynamic API, the reference to its <cluster>-app Secret (never read), readiness from its status, deletionPolicy, and NotInstalled without the CloudNativePG API
crates/objects-kubernetes	aap-objects-kubernetes: AgentObjects on the API server for the Platform API: server-side apply (agents.vymalo.com/dashboard, force off) of the dashboard's four kinds, both applies dry-run first with the version and uid read, GitOps objects never written, the spec as written, offers read from labelled ExternalSecrets, no Secret read; its Role is a file held equal to its calls
crates/auth-oidc	aap-auth-oidc: Authenticator for the Platform API over a bearer JWT checked against an OIDC issuer's JWKS (RS256, RS384, ES256, EdDSA; iss, aud, exp, sub, the roles claim as permissions; a key cache that fails closed; no DPoP); OidcConfig for the API's YAML file; with the feature testkit, an issuer on a local port for tests
crates/platform-api	aap-platform-api: the axum router of the Platform API over /v1, generic over AgentObjects and Authenticator: one table of routes and the permission each needs (ROUTES), problem details with the form field of every 422, ETag/If-Match/If-None-Match preconditions (428 without), secrets.pick decided from the form, dependents_after before a shared write, CORS for exact origins, a log that holds no token, body or secret key
crates/registry	aap-registry: the agent-registry/v1 document builder and an axum router: one static bearer compared in constant time, strong ETag and 304, Cache-Control: private, max-age=30, a refusal rather than a truncation past 500 items or 1 MiB; the system's reader is vendored in its tests
crates/controller	aap-controller: the AgentService and AgentConfig reconcilers (kube-rs), generic over the two providers: finalizer, resolve, store, runtime, conditions and state, Events, the deletion policy, back-off by error class; and ReflectorDirectory, the AgentDirectory over the reflector's cache
bin/operator	aap-operator, binary operator: crdgen prints the CRDs; run composes the Kubernetes provider, the store (CloudNativePG, with store-cnpg) and the controllers, with health (8081), metrics (9090) and, with a token, the registry (8080); tests/cluster.rs and tests/stub are the end-to-end against a real cluster
bin/api	aap-api-server, binary api: the Platform API's composition root: one YAML configuration file (unknown keys refused, validated at load, no secret in it), aap-objects-kubernetes and aap-auth-oidc behind the router, /healthz and /readyz on their own port, a drain on SIGTERM; --check validates the file with no cluster; its image is docker/api and its chart the component api of deploy/operator
deploy/crds	The generated CRDs, checked in; CI fails when crdgen prints something else
docker/operator	The operator's image, ghcr.io/vymalo/another-agentic-platform/operator: cargo-chef on Rust 1.94.1 onto distroless/cc-debian13:nonroot, both pinned by tag and digest, user 65532, only the operator binary
docker/api	The Platform API's image, ghcr.io/vymalo/another-agentic-platform/api: the operator's Dockerfile with the package and the binary changed (same builder and base, user 65532, only the api binary; the build stage smoke-tests it)
deploy/operator	The operator's Helm chart: one replica (Recreate, no leader election), a namespaced Role with exactly the verbs of the crates' READMEs (no Secrets), the registry's Service and token file only with a token (an existing Secret or an ExternalSecret), a NetworkPolicy, bump-tag.sh, render checks with golden renders; and, off by default, the Platform API (api.enabled): its own Deployment, service account, Role and NetworkPolicy, and an optional Ingress
deploy/operator-crds	A chart of the CRDs only (its own Argo CD app, §93): a copy of deploy/crds, held equal by a test
deploy/operator/tests/e2e	The end-to-end of the coder in kind (S9): coder-e2e.sh, examples/coder.yaml adapted to the real image and a Postgres the job runs
tools/adam-parity	Regenerates the parity goldens from the adam-rs chart (by hand: needs helm and a clone of adam-rs)
examples	coder.yaml and chat.yaml (a service and its config each), coder-me.yaml (the dashboard's ModelEndpoint and ToolProvider and a coder that references them), and invalid/, one object per CEL rule and per bound of the dashboard's fields, each refused by an API server

cargo fmt --all --check
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo test --workspace --locked
cargo run -q -p aap-operator -- crdgen | diff deploy/crds/agents.vymalo.com.yaml -   # the drift check

CI is .github/workflows/operator.yml: the four checks above, and a kind job that applies the CRDs, the examples and the invalid examples to a real API server; and .github/workflows/operator-image.yml: the charts' checks, the operator's image and the Platform API's built and smoke-tested (the API's also with api --check on the configuration the chart renders), then on main pushed as sha-<7> and latest, and one commit that bumps both tags in deploy/operator/values.yaml. The parity goldens are tested in CI (against the checked-in files) but regenerated by hand: tools/adam-parity/regen.sh needs helm and a clone of another repository.

Related

• another-agentic-system — a protocol-agnostic orchestration layer (chat surface + stateless orchestrator). It consumes agents over A2A, MCP and webhooks like any other system; when an agent comes from this platform, it offers release selection through the extension above.
• vymalo/another-adam-rs — the agent harness (AD-022): adam-coder and adam-agent, one image, which the v0 operator runs.
• vymalo/another-agentic-images — the toolchain image recipe (Rust, Flutter/Dart, Node, agent CLIs under /opt) coding runtimes start from.

Roadmap and contributing

• Roadmap: the product roadmap to launch, with every open piece of work as an issue, is ROADMAP.md in another-agentic-system.
• Contributing: CONTRIBUTING.md.
• Security: report a vulnerability privately, as SECURITY.md says.

License

MIT. Vendored agent skills keep their own licenses; see third-party-notices.md.