Agentic and AI Features

Agent-readable OpenAPI documentation from the same generated docs tree.

printing press treats agents as a first-class documentation consumer.

HTML is still generated for humans, but every build can also emit markdown, llms.txt, AGENTS.md, and JSON artifacts that are easier for agents and automation to inspect.

Why agent output exists

Raw API contracts are a poor input for agents.

An agent has to parse the document, chase references, compose schemas, understand polymorphic shapes, and build enough of the graph in memory to answer a basic product question.

JavaScript-heavy documentation can be just as expensive: the agent has to open a browser, wait for the DOM to render, and inspect the page as if it were a user.

That burns tokens, forces extra tool calls, and churns cycles inside an agentic harness.

printing press avoids that by generating an agent-readable version of the same documentation.

The important part of this design is creating routes an agent can take: orient itself, choose the right target, load concise task context, then fall back to structured JSON when exact data matters.

Agent navigation model

Agents need a predictable path through an API surface. printing press builds that path around four core jobs to be done:

Orient with AGENTS.md

This gives the agent a solid starting point and a high-level map of the generated docs.

Look up operations and models using the focused LLM indexes, which point at operations, models, and larger summaries.

Read generated markdown

Per-operation and per-model markdown files exist, which carry the same API information as the rendered HTML without requiring browser inspection or any kind of token heavy parsing.

Check structure

JSON artifacts contain schemas, properties and composed models when a tool needs deterministic, compiled, runnable data instead of prose.

That gives an agent a simple execution model: start from the root, find the relevant operation or model, read the markdown context, and inspect JSON only when exact generated structure is needed.

Artifact roles

Each generated artifact has a specific job in the agent workflow.

Artifact Role Use it for
AGENTS.md Agent entry point Orientation, repo-style instructions, and the safest place to start.
llms.txt Compact index Discovering the generated documentation surface without crawling HTML.
llms-full.txt Full context bundle Loading broader API context when the task needs more than one operation or model.
llms-models.txt Model index Finding schemas, compositions, and model-specific markdown.
llms-operations.txt Operation index Finding endpoints, methods, tags, and operation markdown.
operations/*.md Task context Reading request, response, parameter, and operation details in agent-friendly markdown.
models/<type>/*.md Schema context Reading model structure, relationships, and composition details.
*.json artifacts Structured data Tooling, deterministic inspection, or exact generated model data without scraping HTML.

Generated files

LLM output includes root agent files and per-page markdown:

  • api-docs/AGENTS.md
  • api-docs/llms.txt
  • api-docs/llms-full.txt
  • api-docs/llms-models.txt
  • api-docs/llms-operations.txt
  • api-docs/operations/*.md
  • api-docs/models/<type>/*.md

JSON output includes the same generated documentation model in structured form:

  • api-docs/bundle.json
  • api-docs/index.json
  • api-docs/operations/*.json
  • api-docs/models/<type>/*.json

The markdown output gives an agent concise reading material. The JSON output gives tools structured generated data without scraping HTML.

How agents should use it

AGENTS.md and llms.txt operate as indexes for the generated API documentation.

Instead of asking an agent to parse the OpenAPI source directly, point it at the generated docs and ask a semantic question, such as:

How do I create a new payment to a service provider?

The agent should start at api-docs/AGENTS.md, use api-docs/llms.txt or the focused LLM indexes to find the right operation or model, then read the per-operation or per-model markdown that contains the same API information as the rendered HTML.

When the answer needs exact generated structure, the agent can inspect the matching JSON artifact instead of guessing from prose.

All of this means:

  • Less OpenAPI parsing in the harness
  • Less DOM inspection
  • Fewer reference-chasing tool calls
  • Clearer context for operations, models, tags, and generated examples
  • Much faster, far less token burn.
  • A native format for AI!

Catalog agent output

For API catalogs, the agent output becomes hierarchical.

A catalog build starts with root files for the whole API surface:

  • api-docs/AGENTS.md
  • api-docs/llms.txt

Service and version indexes let an agent narrow the search safely:

  • api-docs/services/<service>/llms.txt
  • api-docs/services/<service>/versions/<version>/llms.txt

Each spec entry gets its own generated agent files:

  • api-docs/services/<service>/versions/<version>/specs/<entry>/AGENTS.md
  • api-docs/services/<service>/versions/<version>/specs/<entry>/llms.txt

Start at the root catalog files when you want an agent to discover the API surface. It can narrow into a service, then a version, then the exact spec entry it needs.

Control the output

LLM output is enabled by default. Disable it when a build only needs HTML or JSON:

ppress --no-llm ./openapi.yaml

At least one output family must remain enabled.

Use Outputs for the full output tree, and API Catalog for catalog discovery and grouping.

Try with your own agents

Generate docs from an OpenAPI spec, then point an agent at the generated AGENTS.md and llms.txt files.

Ask the same semantic API question against the raw OpenAPI source and the generated printing press output. The generated output is designed to be faster to navigate, easier to cite, and cleaner for agents to consume.

Ask your agent how the generated docs feel compared to reading a raw spec or HTML/JS-generated docs, and see what it says.

Bet you a million dollars it’ll much prefer the generated output.