What does agent-ready actually look like?

"This surface already exists. The only question is whether you've governed it — or left agents to read you on their own terms."

This is your external surface: the outward face agents form their picture of you from. By default your IBM i system has no presence an agent can navigate — no llms.txt, no structured manifest, no declared policy on what an agent may query or invoke. But the surface is not neutral in its absence. Agents still arrive; they simply read you badly, or route to a competitor whose surface is legible. This layer isn't about being found — it's about being correctly and safely represented to a class of reader that already outnumbers humans on the web.

• Create llms.txt at your domain root declaring agent permissions and your MCP endpoint
• Update robots.txt to explicitly allow or restrict specific agent crawlers
• Publish an MCP server manifest — which tools are exposed, what schemas they expect
• Add Schema.org Organization markup with API contact and capabilities

"Can an agent understand what you do well enough to act on it correctly?"

The business logic that governs your operations lives in RPG programs and Db2 tables. No agent can read RPG directly. But agentic coding tools can surface that logic into human-readable documentation that becomes the foundation for machine-readable specifications. This is the knowledge-extraction step — and it is where decades of encoded logic becomes an asset an agent can finally reach. It is the work of closing Knowledge Distance on the technology side.

• Document the Db2 schema — table names, field definitions, relationship maps — in structured form
• Use agentic coding tools to extract RPG program logic into readable specifications
• Publish an OpenAPI spec describing your core endpoints
• Express machine-readable terms and thresholds in JSON-LD

"Can an agent reach the sovereign core — without changing it?"

This is the bridge layer: APIs and the MCP interface that make RPG and Db2 reachable and agent-legible without rewriting the core. The encoded logic stays exactly where it is, protected at the center; the access layer exposes it on terms you define. This is where IBM i's reliability becomes an agentic advantage rather than a constraint.

• Stand up an MCP interface mapping IBM i programs and queries to agent-callable tools
• Use a modern data interface to expose Db2 for i safely to the access layer
• Scope each exposed tool with explicit, least-privilege permissions
• Keep the core unchanged — reach it, don't rebuild it

"When an agent acts, can you prove what it did — and stop what it shouldn't?"

Governance is the layer that makes everything above it safe, which is why it is built into the foundation rather than bolted on at the end. Every agent action authenticated, permissioned, and logged. Runtime enforcement, deterministic policy, and an audit trail are not features you add later — they are the precondition for letting an agent near the core at all.

• Authenticate and authorize every agent at the boundary, per tool
• Enforce deterministic policy at runtime — not just at design time
• Journal every agent action to an immutable audit trail
• Build this layer first, so execution never outruns it

"Can agents do real work — under human governance — at agentic speed?"

With the four layers beneath it in place, agents can execute real work against the systems that run the business — querying, comparing, acting on behalf of customers — while humans govern strategy, judgment, ethics, and escalation. This is human-agentic operation: agents execute, humans govern, the sovereign core stays protected the whole way.

• Stand agents up thoughtfully, in tandem with organizational readiness
• Prove on one slice — a pilot or agentic twin — before scaling
• Keep humans at the points where judgment belongs
• Scale only as fast as the governance layer can hold