Managing AI agent config across hundreds of microservices

It is Markdown all the way down

The thing every one of these tools quietly agreed on is that agent context is plain Markdown. That is the good news - it means the whole config surface is greppable, diffable, and openable in one editor. It is also the problem, because Markdown has no schema, no owner, and no map.

Kiro leans hardest into structure: its steering files (product.md, tech.md, structure.md) carry persistent project context, and its spec-driven mode splits a feature into requirements.md, design.md, and tasks.md. Claude Code layers a hierarchy of CLAUDE.md from your home directory down through the repo and into subdirectories, plus reusable skills and subagents as their own Markdown files. Cursor uses .mdc rule files with front matter for globs. Different names, same substance. Here is one company modeled two ways - the same shared standards and tickets, but a Claude Code estate versus a Kiro one:

~/.claude/CLAUDE.md                    # you, on every repo
platform-standards/                   # company-wide vault
  security.md                         # [[linked]] by every service
  api-conventions.md
services/payments/
  CLAUDE.md                           # service-local
  .claude/commands/deploy.md          # a skill
  .claude/agents/reviewer.md          # a subagent
infra/terraform/CLAUDE.md             # the infra agent's context
tickets/PLAT-1421-rate-limit.md       # status: in-progress

platform-standards/                   # company-wide vault
  security.md                         # [[linked]] by every service
  api-conventions.md
services/payments/
  .kiro/steering/product.md           # persistent context
  .kiro/steering/tech.md
  .kiro/specs/refund-flow/
    requirements.md                   # EARS acceptance criteria
    design.md
    tasks.md
infra/.kiro/steering/tech.md
tickets/PLAT-1421-rate-limit.md       # status: in-progress

The problem is governance, not generation

Every one of those files is optimized for an agent to read, not for a human to steer. At a few dozen services you hold it in your head. At a few hundred you get the failure modes of any un-owned knowledge base: the same rule copy-pasted into forty repos and now drifting; a company security standard that three services silently override; steering docs that outlived the service they described; and the recurring question no tool answers cleanly - which instruction actually applies to the agent working in this directory, and why?

None of the coding tools solve this, because it is not their job. They resolve config for the agent, at runtime. They do not give a human a map of the whole thing.

A native vault over the tree

This is where a Markdown knowledge base earns its place - not as another config format, but as the human-facing layer over the ones you already have. Point Metis at the tree (a monorepo, or a curated context vault) and the config stops being a scatter of files and becomes something you can navigate:

• Links and a graph. A service's steering doc that [[links]] the company standard it inherits makes the inheritance explicit - and the graph then shows you the orphans (a steering doc nothing points to) and the hotspots (the one standard four hundred services depend on, so you touch it carefully).
• Search across everything. Keyword search with path: and tag: operators, plus on-device semantic search, finds every place a rule was duplicated instead of referenced - the raw material for de-duplicating the drift.
• Typed properties as governance metadata. Give each steering doc an owner, a status, a last-revieweddate in YAML front matter. Now "show me every unowned or stale steering doc" is a query, not an audit.

And the payoff that ties it together: the same vault is what the agents read over Metis's built-in MCP server. Your governance layer and the agent's context are not two copies that drift - they are one store.

Tickets and progress live in the same place

The config is only half of it. The other half is the operational knowledge that wraps a system this size - domain and business knowledge, runbooks, the tickets in flight, what shipped last week. In most shops that is smeared across a wiki, a tracker, and a chat history, none of which the agent can see.

Kept as Markdown in the same vault, a ticket is a note with status, owner, service, and duein its front matter, and Metis rolls every such note into one agenda - Overdue, Today, Upcoming - scoped to a folder when you want just one service's queue. Because it is the same vault the agents read, the agent working the refund-flow spec can pull the linked ticket, the service runbook, and the company API standard in one hop - and write its progress back with create_note. Governance, knowledge, and work items stop being three systems.

Where it stops

The honest boundaries, because a post that only sells is not worth your time.

• Metis opens a folder tree, not your whole GitHub org. It is a native vault over a directory - a monorepo, a curated context vault, or one service's docs. It does not crawl hundreds of separate repos and aggregate their scattered CLAUDE.md files for you. If your config lives in three hundred repos, the realistic pattern is a dedicated platform-context vault that references them, not a magic cross-repo index.
• It is not a config resolver. Metis will not compute which rule wins when a user, a service, and a company steering doc disagree - that precedence lives in each tool's runtime. Metis makes the hierarchy visible and owned; it does not evaluate it.
• The MCP write path is create, not rewrite. Agents can read and search the vault and append new notes; editing or deleting existing files through the server is not wired up. For governed config that is the behavior you want - an agent should not silently rewrite your security standard - but it is a real limit, not a completeness claim.

Why native, local, and private matter here

Two properties stop being nice-to-haves at this scale. First, native: a vault of thousands of steering docs, specs, runbooks, and tickets has to open and search without lag, and a persistent index over a native app is what makes that hold up where an Electron notes app starts to crawl. Second, local-first and private: this material is your infrastructure topology, your security posture, your unshipped roadmap. Metis keeps it as plain files on the machine, and its AI - Ask Vault, summarize - runs through Apple's on-device Foundation Models, so asking "what do we do about rate limiting across services?" across the whole vault sends none of it to a server. A cloud notes tool cannot make that promise about your internal estate.

The tool

Metis is a native Markdown knowledge base for Mac, iPad, and iPhone - vault, links and graph, typed properties, agenda, git history, on-device AI, and the built-in MCP server described here. There is a focused write-up of the agent side on the knowledge base for AI agents page. One-time $14.99, 7-day free trial, no subscription - and your files stay yours either way.