Agent-Native Systems and Skill Graphs

There's a growing conversation around skill graphs. Composable pieces that reference each other, progressive disclosure through metadata, agents that traverse a graph instead of reading one massive file. That's the pattern. I know because I shipped a system built on it.

Here's what I learned along the way.

The ceiling everyone hits

It didn't start with skills. It started with markdown files. Notes on how to run research, write a PRD, structure a sprint. Knowledge and judgment, written down so I could feed it to whichever AI tool I was using that week.

That worked until product work got in the way. Research informs strategy. Strategy shapes what you design. Design decisions show up in specs. Specs drive sprint planning. Everything connects.

So the files grew. Business context. User personas. Competitive landscape. Brand voice. One file trying to hold methodology, business knowledge, and reusable patterns all at once. I'd hit context limits, switch tools, realize the file was too coupled to one environment, and start over.

That's the ceiling. The instinct is to write a better file. Tighter instructions, more examples, clearer structure. That helps, but it doesn't solve the fundamental problem: one file is doing too many jobs, and it only works in one place.

The solution is a skill graph. An agent-native system. Modular pieces with explicit connections that an agent can traverse without human orchestration.

Three layers, not one file

The answer I landed on has three layers.

The first is skills. A skill is a complete methodology for one domain. Not a prompt. A methodology. Research synthesis doesn't just say "do research." It defines how to plan a study, write a discussion guide, run interviews, synthesize findings, and validate insights. It teaches the agent how a senior product person actually does the work. Twelve of these, covering the full product lifecycle.

The second is context. Your business-specific knowledge, separate from any skill. Identity, voice, user personas, product details, competitive landscape, pricing, visual identity. Context doesn't tell the agent what to do. It tells the agent who you are. When a skill loads your context, the output stops being generic and starts sounding like your team wrote it.

The third is frameworks. Reusable methodologies that aren't owned by any single skill. Prioritization, decision-making, messaging, stakeholder communication, research methods, workflow orchestration. The prioritization framework gets used by strategic advisory and project management. The messaging framework gets used by product marketing and go-to-market. Shared patterns, loaded where they're needed.

Three layers, each modular, each composable. Skills provide methodology. Context makes it personal. Frameworks give structure. The pieces connect, but they're maintained independently.

Every file is one complete thought. A skill is a node. A context file is a node. A framework is a node. The edges between them are what make the system work.

The canonical instruction file

Modular pieces don't help if the agent doesn't know how to find them. This is the problem I see in most setups: files exist, but nothing tells the agent which ones matter for the current task.

The solution is a single instruction file that acts as the routing layer. One file the agent reads first, every time. It maps tasks to skills, tells the agent where to find manifests, defines the execution protocol, and sets the rules for how context loads.

You describe a task. The instruction file routes it. The agent knows exactly where to go.

A canonical instruction file goes beyond describing what exists. It defines how the agent should behave, what sequence to follow, and what rules to enforce. It's the operating system for the skill graph.

This is the piece that makes the system agent-native. The agent isn't guessing what to load. It isn't scanning a folder hoping to find the right file. It reads one canonical file that tells it how the entire system works, and then it follows the path.

No human orchestration required.

The manifest pattern

Every skill has a manifest.yaml. A dedicated file that tells the agent what to load before doing any work.

A manifest lists three things:

always_load: The skill file and its core frameworks. These load every time the skill runs.

context: Business-specific files. Identity and voice load into every skill. Then each skill declares what extended context it needs. Research synthesis loads user personas and competitive landscape. UX design loads users, visual identity, and technical constraints. Each skill pulls in exactly the context that matters for its domain.

references: Detailed reference materials. Interview guides, design patterns, document templates, experimentation methods. These load when the task needs depth.

The agent reads the manifest first, before reading any content. It knows what exists, what matters, and what to skip.

This is what makes the system a graph, not a folder. Every skill node connects to context nodes, framework nodes, and reference nodes through its manifest. The manifests define the edges. The agent traverses them. Progressive disclosure through dedicated manifest files that declare exactly what each skill needs.

Why context is a separate layer

This is the insight that changed how I built everything.

Most people building AI workflows focus on the skill. The methodology, the instructions, the system prompt. That matters. But it's half the equation.

A research synthesis skill without your user personas produces generic findings. A product marketing skill without your competitive landscape produces generic positioning. A UX design skill without your visual identity produces generic wireframes.

Good instructions with no context produce polished generic output. Average instructions with rich context produce specific, useful output. Good instructions with rich context produce output you actually ship.

That's why context is a separate layer. You write it once. Every skill benefits. When you improve your identity file, every skill that loads it gets better. When you add competitive context, strategy and marketing both level up. The investment compounds across the whole system.

The graph structure matters. The linking patterns, the traversal, the topology. But the content of the nodes matters just as much as the connections between them. A beautifully connected graph of generic knowledge still produces generic output. Context is what makes the graph yours.

Workflow orchestration

Architecture gets you the right files in front of the agent. Workflow orchestration is how the agent actually does the work once it has them.

Every skill in Baseline Core follows the same meta-workflow. The domain changes, but the execution pattern doesn't. This consistency is what makes the system predictable across twelve different skills.

Four principles govern all work:

Simplicity first. Every solution should be as simple as possible. Before accepting an approach, ask: is there a simpler way that solves the same problem? Complexity should be justified, never defaulted to. If you can cut it, cut it.

Root cause focus. Understand deeply before solving. Don't fix symptoms. Ask "why" until you reach the real problem. A correct diagnosis matters more than a fast solution.

Demand elegance. For non-trivial work, pause and ask: is there a more elegant way? If a solution feels forced, explore alternatives. The right framing often makes the solution obvious.

Verification before done. Never mark work complete without proving it works. "I think it's done" is not done. Test your output. Demonstrate correctness. If you can't verify it, it's not finished.

The execution follows a five-step pattern:

Plan before executing. Align on approach before doing any work. This is mandatory for every skill invocation. State your understanding, outline the approach, identify what context to load, note open questions, and wait for approval. Planning prevents wasted effort. It's faster to course-correct a plan than to rebuild finished work.

Clarify before starting. Gather essential information. If answers are missing or ambiguous, ask directly. Don't assume. Don't proceed with incomplete information. An expert gathers what they need to do excellent work.

Load relevant context. Ground the work in organizational knowledge. Core context always loads. Extended context loads based on the skill. References load when the task needs depth.

Execute domain-specific work. The skill defines the approaches, when to use each one, how to execute, and what deliverables to create.

Quality checks. Validate that work meets standards before considering it done. Binary pass/fail. If it doesn't pass, it's not done.

When quality checks fail, error recovery kicks in. Identify what specifically isn't working. Diagnose why. Unclear requirements go back to clarification. Missing context means loading additional files. Wrong approach means trying a different path from the skill's methodology. Apply the fix, re-run quality checks, repeat until everything passes. If recovery attempts don't resolve it after two or three tries, escalate. Don't spin endlessly.

Session management matters more than people expect. Context quality degrades before it runs out. Long, dense conversations lead to less precise output, forgotten decisions, and repeated mistakes, often without obvious warning. One major task per session. Start fresh after milestones. A new session with clear context outperforms a fatigued session every time.

This orchestration layer is what separates a collection of files from a system. The architecture tells the agent what to load. The workflow tells it how to work. Both have to be right.

What agent-native actually means

There's a difference between a system that works with AI and a system designed for how agents actually operate.

Most AI workflows are human workflows with AI bolted on. You still decide what to load. You still paste in context. You still manage the orchestration. The AI does the writing, but you do the thinking about what it needs to do the writing.

An agent-native system flips that. The agent reads the instruction file. It identifies the right skill. It reads the manifest. It loads the context, the frameworks, the references. It plans the approach, asks clarifying questions, executes the work, validates the output.

The human says what they need. The system handles how to get there.

This only works if the architecture was designed for it. Modular files the agent can load independently. Manifests that declare dependencies explicitly. A canonical instruction file that defines the routing. A workflow orchestration layer that standardizes how work gets done. Clear separation between methodology, knowledge, and patterns so the agent can compose them dynamically.

That's what I mean by agent-native. Not "works with AI tools." Built for how agents think.

Building for agents, not for yourself

The biggest lesson from building this: stop thinking about what you need the AI to know. Start thinking about what the agent needs to navigate.

Agents don't read the way humans do. They don't benefit from long, comprehensive documents. They benefit from small, composable pieces with clear metadata that tells them what's relevant and what to skip.

A manifest is more useful than a longer skill file. A separate context file is more useful than context pasted into a prompt. An instruction file that defines routing is more useful than hoping the agent figures out which skill to use. A workflow pattern that standardizes execution is more useful than hoping the agent figures out how to work.

The primitives are simple. Markdown files. YAML manifests. One instruction file. No special tooling, no plugins, no platform dependencies. Just files organized in a way that agents can traverse.

The architecture is what matters. Get the architecture right and the system works with any AI tool. The same file structure works with Claude Code, Cursor, Windsurf, Codex, GitHub Copilot, JetBrains AI. The agent reads the instruction file and knows what to do.

Agent-native means the system is portable. It's not locked to a platform. It's locked to a pattern.

Baseline Core

This architecture is the foundation of Baseline Core. Twelve skills, 14 frameworks, 34 reference files, workflow orchestration, and a canonical instruction file. Open source, MIT licensed, free forever.