The Agentic Web: Why AI Agents Need a Resume (Arscontexta Skill Graph)

Everyone is building agents. Almost nobody is connecting them.

The current approach to agentic workflows relies on hardcoded API connections and massive system prompts. This creates an O(n) token tax where every new tool degrades model reasoning. The Arscontexta framework solves this by moving capabilities out of the prompt and into a Skill Graph—a three-space markdown architecture using self, skills, and ops directories. Instead of reading 50 tools at once, the agent navigates a folder of SKILLS.md files to discover what it needs exactly when it needs it.

If an orchestrator agent needs a sub-agent to complete a task, developers usually hardcode the connection. You end up writing routing logic pointing directly to a specific endpoint. That is not an agentic web. That is just traditional microservices with a slower, more expensive API.

The industry knows this is a problem. Groups like the Agentic AI Foundation are pushing for standardized A2A (Agent-to-Agent) protocols. Anthropic recently shipped the Model Context Protocol (MCP) to help standardize connections.

But developers misunderstand what MCP actually does. MCP is a transport layer. It standardizes how an agent connects to a database or a file system. It does not solve the cognitive layer. Before two independent agents can work together, they need to know what the other is capable of. They need an explicit identity. They need a resume.

The Token Tax of Massive System Prompts

Right now, developers handle capability discovery by stuffing every available tool into the system prompt. If you have 50 tools, the LLM reads the schemas for all 50 on every single turn.

I call this the token tax. It scales at O(n). As your system gets more capable, it gets slower, more expensive, and noticeably dumber. This is a physics problem: attention is a finite resource. When you flood the context window with tool definitions the agent isn't using yet, you increase the noise-to-signal ratio. The model starts hallucinating parameters or missing subtle instructions because its attention heads are spread across 40 irrelevant JSON schemas.

The solution is an architecture that lets the agent navigate to what it needs dynamically. We do not need complex XML schemas to solve this. We just need plain text that both humans and LLMs can read.

Every distinct agent or capability gets its own markdown file. This file acts as a manifest. A good SKILLS.md file defines three explicit things:

1. Triggers: When should another agent call this skill?
2. Instructions: How exactly does the agent execute the task?
3. Boundaries: What is the agent absolutely not allowed to do?

Imagine an orchestrator agent ingesting messy JSON. A payload comes in containing a social security number. In a hardcoded system, this pipeline either breaks or logs the unencrypted data.

In an agentic system, the orchestrator pauses. It searches its environment for a skill that handles PII. It finds pii-scrubber/SKILLS.md:

# Identity: PII Scrubber Agent
 
## Triggers
- Use this whenever a JSON payload contains suspected PII (SSNs, Credit Cards).
 
## Instructions
1. Scan input for PII patterns.
2. Replace matched patterns with [REDACTED_PII].
 
## Boundaries
- Never make external network calls.
- Never write unredacted payloads to disk.

The orchestrator reads this, understands the boundaries, and passes the data. It didn't need to know the scrubber existed until the exact millisecond it was required.

Scaling Agents with the Arscontexta Skill Graph

Instead of a monolithic instruction file, you build a Skill Graph. This is a network of individual markdown files connected by standard wikilinks.

The Arscontexta framework splits the agent's brain into three distinct spaces:

1. self/ — The core directives, personality, and high-level mission.
2. skills/ — The library of capability files and Maps of Content.
3. ops/ — The persistent ledger of what happened and what happens next.

To navigate the skills space without blowing the context window, the agent relies on three primitives.

1. Progressive Disclosure

Agents should never read the whole graph at once. They start at an index, scan the YAML descriptions of linked files, and only load the full document if the description matches the task. This hierarchy saves tokens and maintains focus.

2. Contextual Links

A link standing alone lacks signal. In a Skill Graph, links are woven into prose. The agent reads that before sending user data to an external API, it must route it through the [[PII Scrubber]]. The surrounding text provides the actual reasoning—the why behind the link.

3. Maps of Content

As skills multiply, you cluster them. A Map of Content acts as a routing hub for related capabilities. A Data Processing node links the scrubber, the formatter, and the validator in one place.

The Tool Discovery Tradeoff: Context vs Latency

There is no free lunch. Moving from a massive system prompt to a Skill Graph trades context space for latency.

When tools are in the prompt, the agent acts immediately. When tools are in a graph, the agent must browse first. This adds 1-2 inference turns to the start of a complex task. For simple, repetitive scripts, stay with hardcoded tools. But for open-ended research, multi-step engineering, or autonomous operations, this latency is the price of scale. You are trading a few seconds of browsing for the ability to support 5,000 tools instead of 50.

Fixing Agent Amnesia with the Ops Ledger

The biggest trap with autonomous agents is the drop in context between sessions. You do not fix this by cramming chat history into the prompt. That just accelerates the token tax.

Instead, you decouple state management into the ops space. Think of this as a ledger. As the agent finishes a step, it logs the outcome to an ops/ledger.md file.

When the agent wakes up for the next step, it reads the ledger. State becomes an explicit file. Unlike RAG (Retrieval-Augmented Generation), which is great for fetching static facts, the Ledger is designed for dynamic state. You can see exactly where a workflow stalled by reading a markdown document instead of digging through JSON logs. This makes it incredibly simple to hand off tasks between completely different agents. If the orchestrator dies, the next agent picks up the ledger and knows exactly where the previous one left off.

How to Build a Skill Graph with Claude Code

The theory sounds great. Hand-writing 250 interconnected markdown files is a massive waste of time.

If you are building this manually, start by creating a directory_map.md in your skills folder. Give the agent a single tool: read_file. Tell the agent its first step for any unknown task is to read that map.

For a more automated approach, I use the Arscontexta plugin for Claude Code. It is an engine that derives your local knowledge system for you through conversation.

Here is how the mechanics work in practice:

• Scaffold the structure. You point Claude Code at a directory and describe your target workflow. The plugin maps the territory. It generates the folder hierarchy, indexes, YAML frontmatter, and the wikilinks connecting them.
• Ingest on the fly. When you solve a hard problem, you do not stop to manually format a note. You run the learn command and pass in the raw context. The agent extracts the core skill, creates the node, and wires it into the graph.
• Compress the noise. As you pump information in, the system naturally gets messy. You run the reduce command to force the agent to synthesize overlapping notes, consolidate redundant patterns, and update your indexes.

The leverage here is massive. You stop acting as a data entry clerk for your own brain and start acting like a systems architect. The agent handles the boilerplate. You just guide the structure.

This covers the identity and discovery layer. But discovery is only half the battle. In Part 2, I will break down how these agents actually trust each other once they read the graph using DeepMind's Intelligent AI Delegation framework.