← Builds on How

01–06 · About 5 minutes

Software now has three experiences to design for.

Humans get a UX. Developers get a DX. The newest reader gets an AX — and most platforms haven’t built one yet.

01 — Three experiences

UX. DX. AX.

UX User Experience The platform is enjoyable to use — clear, fast, forgiving of human attention.
DX Developer Experience The platform is easy to integrate — clear docs, a clean API, predictable behaviour.
AX Agent Experience The platform is naturally usable by an intelligent agent acting without a human watching every step.

AX isn’t UX simplified, or DX automated. It’s a third reader with its own requirements.

02 — What this looks like

Things you can now just ask for.

Each of these is a real sentence someone can type into an AI coding assistant today.

❭ Install EigenVertex on this Ubuntu server.

The assistant reads the deployment knowledge, asks what it doesn’t know, and installs it.

❭ Configure EigenVertex for a private VPC, no external traffic.

The assistant adjusts the deployment itself, not just a settings page.

❭ Integrate EVTX into this Next.js app.

The assistant wires the API client, auth and error handling — not a generic snippet.

❭ Build an EVTX chat panel inside our existing dashboard.

The assistant generates components, streaming and styling that match the app, not a demo.

❭ Connect EVTX to our MCP agent.

The assistant wires the MCP server using the same contract a human developer would call.

❭ Why is this EVTX deployment slow today?

The assistant reads the runbooks, checks the architecture, and reports what changed.

None of these are chatbot tricks. They’re tasks an assistant can actually finish.

03 — The Agent Kit

A second set of docs — written for a reader that doesn’t skim.

Human documentation is written to be read in order, with judgment filling the gaps. An agent doesn’t fill gaps — it needs the gap itself written down.

The EVTX Agent Kit is a structured set of knowledge assets built for that reader: precise, scoped, and meant to be executed against, not just read.

evtx-agent-kit /

install.md Architecture, dependencies and the exact steps to stand EVTX up.
deployment.md Managed, private cloud or on-premise — the decisions and trade-offs for each.
architecture.md The stack, named — what is structural, interchangeable or optional.
authentication.md API keys, scoped workspaces, and how access is actually enforced.
chat-ui.md How to embed multimodal chat into an existing application.
openapi.md The machine-readable contract behind every endpoint.
mcp.md How an MCP agent connects, authenticates, and calls EVTX as a tool.
examples/ Minimal, runnable integrations across common stacks.
recipes/ Composed prompts for the tasks teams actually ask for.
prompts/ Reusable instructions an assistant can load instead of guessing.
runbooks/ Diagnosis steps for the questions that start with “why is this slow”.

These aren’t documentation for humans who happen to skim faster. They’re knowledge assets built to be consumed by something that doesn’t skim at all.

04 — Executable documentation

Documentation an assistant can run, not just read.

A human reads install.md and does the work. An assistant reads install.md and does the work too — the difference is it can ask, decide and act in the same pass.

That’s the whole idea behind executable documentation: the document isn’t a description of the task. It’s close enough to the task that an agent can execute it directly.

“Install EigenVertex on this Ubuntu server.”
01 Read Loads install.md and architecture.md — dependencies, requirements, sequence.
02 Ask Resolves what it doesn’t know: domain, scale, secrets, network policy.
03 Deploy Runs the installation against the target server, step by step.
04 Validate Checks the result against the same criteria a human operator would.

The assistant isn’t guessing from a blog post. It’s following the same source a human engineer would have used.

05 — From API to agent

The API is the foundation. The Agent Kit is what’s built on it.

Each layer below is a real, separate building block — not a rebrand of the one above it.

01 REST API The same OpenAI-compatible surface the product already calls. See the API →
02 OpenAPI A machine-readable contract — every endpoint, typed and named.
03 MCP A standard agents already speak, so EVTX shows up as a tool, not a foreign integration.
04 Executable Documentation Knowledge assets precise enough to act on, not just read.
05 Agent Kit Install, deployment, architecture, auth, chat UI — packaged for an agent reader.
06 Prompt Recipes Composed instructions for the tasks teams actually ask an assistant to do.
07 AI Coding Assistant The human’s actual interface to all of the above — a sentence, not a ticket.

The API was never the ceiling. It was the foundation everything else here gets built on.

06 — What’s next

The Agent Kit is rolling out alongside the API it’s built on.

Some of these assets already exist inside the product. Publishing the full kit is in progress — talk to us if you want early access.