Refine the Model section in docs/concepts.md to directly describe it as a
declarative configuration resource for model providers, parameters, and
credentials rather than using colloquial phrasing.
Fixes#356
* docs: add Substrate prerequisites; demo: fail early if Substrate missing
AX depends on a running Agent Substrate installation, but the README only
mentioned that the Control API must be 'reachable' without saying how to
install Substrate, and demo.sh only surfaced a missing Substrate as a late
ActorCreationFailed task condition (or a 180s timeout).
- README: add a Prerequisites section under Quick start with Substrate
install commands (existing cluster and kind), the expected ate-system
namespace/Control API address, and verification steps.
- demo.sh: add a preflight step that checks the ax CLI exists, kubectl is
available, and the Substrate Control API Service is present (namespace
configurable via SUBSTRATE_NAMESPACE) before mutating any state.
* docs: link to Substrate install instructions instead of duplicating them
Per review feedback, the copied install commands would drift from the
Substrate repo; keep only the link, the expected namespace/Control API
address, and a single verification command.
---------
Co-authored-by: Aditya Shantanu <aditya-shantanu@users.noreply.github.com>
Reduce the sleep interval in the wait_for polling loop from 2s to
0.2s. This allows the demo script to detect task phase and condition
transitions (readiness, suspension) much faster without waiting out
unnecessary 2-second sleep delays.
Remove the Gateway resource across the API, controller, server, CLI,
store, and documentation.
Gateway introduced an unnecessary layer and architectural bifurcation
between Agent Substrate and AX. By removing it, AX aligns directly with
Substrate's native primitives and networking rather than maintaining an
overlapping ingress/routing abstraction.
- Reserved protobuf field 8 and removed Gateway RPCs and messages.
- Cleaned up controller reconciler, server endpoints, and store models.
- Updated CLI, documentation, and example manifests.
AX is undergoing a significant redesign, moving away from a single CLI with
an embedded Python harness toward a general-purpose orchestration layer for
agentic tasks. The repository is reorganized around three binaries: ax-server
exposes a gRPC API for submitting Task manifests, ax-controller runs as a
horizontally scaled reconciler that consumes work from Redis Streams, and
ax-task-runner executes tasks inside sandboxed workers. Task state now lives
in Redis rather than Kubernetes CRDs so the system can handle millions of
short-lived tasks without straining etcd. The legacy Python harness, ATE
client, SQL event log, and skill examples are removed, and new design,
concepts, manifest, networking, runner, and sandbox docs plus Kubernetes
deploy manifests describe the new architecture.
We want AX to be compatible with the Interactions API protocol as much as possible. This PR aligns the proto with Steps and with the Interactions semantics. We will follow up with more changes to make it more compatible with Interactions while preserving a `conversation_id` based history model.
`ConversationService` is removed for now until we know what kind of data operations we want to provide for event log management.
Introduce a local skills source parallel to the Gemini Enterprise Skill
Registry integration. A local source points at a directory already on disk
(a parent dir holding <skill-id>/SKILL.md subfolders, the same layout as
examples/skills and a registry's target_dir); nothing is fetched and the
directory is used as-is.
- New mode-agnostic result shape (internal/skills: Available/Group/Skill) so
both sources feed the same consumers without either depending on the other.
- internal/skills/local.Discover enumerates enabled local paths, treating
immediate subfolders with a SKILL.md as skills (subfolder name = id). It is
fail-safe like registry materialization: a missing/unreadable/empty path is
logged and skipped, never blocking harness creation.
- config.SkillsConfig gains Local []LocalSkillsConfig (enabled + path) with
validation; geminienterprise.Materialize now returns skills.Available.
- cliutil combines registry and local groups into one system-instruction
pointer for the Antigravity Interactions harness. The Antigravity SDK
harness (SKILLS_DIR-based) is left as a TODO.
Only the interactions harness is wired; tests cover discovery, fail-safe
degradation, config validation, and the examples/skills fixture.
Jaana Dogan