Not the devops wizard who loves tmux. Not the YouTuber with fancy terminal themes. The agent organizing your data is the one who does.
We've all had the epiphany moment. Maybe it was Karpathy's note about agentic LLM wikis. Maybe it was watching your Obsidian vault grow into a durable format. Maybe it was realizing that git was already tracking every change, every version.
The pieces were all there. Markdown, links, knowledge graphs, Git. And yet, nobody had shipped the whole thing.
The core idea is great, but give your agent a mechanical question, and watch it go in circles:
> Fix any broken links
read notes/a.md → 1,400 tokens
read notes/b.md → 1,100 tokens
read notes/c.md → 900 tokens
(... 124 files later)
✻ Jitterbugging… (4m 19s · thinking with high effort)
It's rereading everything each time, one file at a time, and you're paying for every token.
What I tried first
Obsidian launched a CLI alongside the desktop app. I tried it. The downside was immediate: it needs the desktop app running. It's designed as a companion tool, not something you'd run on a server at scale.
So I decided to build my own. I called it obsy. Got a few things working, but then stopped.
The reason was simple. What my agent needed wasn't a better notes app. It was a composable markdown engine.
The structure behind your files
Look at what's already sitting in your notes:
---
type: task
status: blocked
tags: [docker, networking, infra]
priority: high
---
# Fix docker networking on staging
- Staging can't reach the internal registry.
- DNS resolution fails for `registry.internal:5000`.
See [DNS setup](/projects/infra/dns-setup.md) and the
[registry config](/projects/infra/container-registry.md).
That's it. Markdown. YAML frontmatter. Standard links. It's portable and durable.
But read again. type, status, tags, priority. Those aren't decoration. They're structured fields. And those links at the bottom? They're edges in a graph.
A few hundred of these files and you start asking yourself:
If I can run
SELECT * FROM tasks WHERE status = 'blocked' AND tags LIKE '%docker%', why can't we do the same with a collection of Markdown files?
So I ended up building a CLI that treats your wiki bundle as a database. Engineered by a human, implemented by an agent. Enter wiki CLI.
In a nutshell
wiki is a general purpose tool for the terminal that:
- Indexes a folder structure
- Indexes the link graph
- Answers structured queries against your bundle
- Performs mechanical transformations and checks on it
- Responds in milliseconds, not in minutes
- Runs on any computer or server
- It's OS and client agnostic
What your agent gains with it:
Free graph navigation
wiki backlinks /projects/infra/dns-setup.md # every entry that points here
wiki links /projects/infra/dns-setup.md # what the entry points to
wiki orphans # entries nothing links to
wiki unresolved # links to pages not written yet
Database-like queries
Filter entries, so that only the relevant few need to be processed.
# Filter
wiki list --where type=task --where tags=docker
# key!=value negates
wiki list --where type=task --where status!=done
# All words
wiki search "container networking"
Pull them as structured data you can transform:
wiki list --where type=task --where status=blocked \
--format json | jq '.[] | {date, tags}'
Extracting checklist items
Extract tasks hiding inside your prose, - [ ] checkboxes scattered across files:
wiki checkboxes --prefix /backlog # every open item, gathered within /backlog/**
Renaming safely
wiki move /topic.md /archive/topic.md # relocate or rename, rewriting every link to it
wiki check # health lint: broken links, untyped entries, drift
wiki tidy --all # normalize links, file names, wikilinks, etc
Rename a file and every link across the base follows in one pass, relative links included. No dead references, no find-and-replace roulette.
Exporting tabular data
So, an agent prepared an invoice list?
---
type: dataset
---
## Invoices
|id |date |description |amount |currency|
|----------|----------|-------------------|-------|--------|
|INV-001 |2026-01-15|Web design project |1200.00|EUR |
|INV-002 |2026-01-20|Consulting fee |850.00 |USD |
|INV-003 |2026-02-01|Hosting services |150.00 |EUR |
|INV-004 |2026-02-10|API integration |2000.00|USD |
|INV-005 |2026-02-15|Support contract |300.00 |EUR |
Well, markdown tables work as well:
wiki table /finance/invoices.md --format csv | duckdb -c \
"SELECT currency, sum(amount) FROM read_csv_auto('/dev/stdin') GROUP BY currency"
┌──────────┬─────────────────┐
│ currency │ sum(amount) │
│ varchar │ double │
├──────────┼─────────────────┤
│ EUR │ 1650.0 │
│ USD │ 2850.0 │
└──────────┴─────────────────┘
The good news is that you didn't wire any of it. Your agent did it, sourcing a durable format without reinventing the wheel.
There's more to explore here, but you get the idea:
Use tokens where needed.
Use compute when it counts.
Hand the mechanical part to a tool that does the exact work, instantly and for next to nothing.
For a decent knowledge base, that's the difference between burning tokens and sub-second answers.
But there's still a missing piece.
Teaching your agent to drive it
Claude can write the finest scripts of the decade, but it knows nothing about the wiki CLI. And it knows nothing about your expected workflow.
wiki could be used with a myriad of shapes. The workflow is what makes it yours:
- What's worth capturing
- When a rough note is ready to promote
- How entries should link
- How your backlog is structured
- How to handle duplicates, etc.
You can scaffold a starter with common conventions already wired in:
wiki init --workflow product-docs
This creates two files that matter:
-
AGENTS.md: general instructions for your agent. It tells it how to operate a wiki bundle with the CLI. -
WORKFLOW.md: the conventions for your knowledge base. How your entries are filed, what types to use, how things are linked. It's a starting point. Edit it to match how you think.
You can also load a reusable SKILL.md on projects that go beyond a knowledge base: https://github.com/agentic-wiki/skills.
What you can build
Once you see the pattern, you cannot unsee it.
- A personal knowledge base
- A team's knowledge base
- A kanban board
- Product documentation
- Tabular datasets
- All the above combined
Same primitive. Same engine. Same agent. Your conventions. Your flow. Your data.
None of this is new in isolation. The Zettelkasten method, the format, Claude, Codex, Gemini, Hermes, Pi calling CLI tools. But together, they close the loop between "my agent reads things" and "my agent manages my knowledge."
All, in a format that both you and your automation flow can read.
Give it a try
Wiki works on macOS, Linux, WSL or Windows.
brew install agentic-wiki/tap/wiki
# or:
# go install github.com/agentic-wiki/wiki/cmd/wiki@latest
Or grab the binary from GitHub releases.
Scaffold a wiki bundle with a workflow starter; default is the general-purpose one:
wiki init --workflow product-docs # Creates AGENTS.md and WORKFLOW.md
wiki status # counts: entries, links, tags, checkboxes, broken links, orphans
Then point your agent at the folder and give it some work:
pi -p "Please, walk the codebase under ~/code/my-project and scaffold a wiki bundle
with the relevant concepts, components and examples as the project knowledge base.
Also, prepare a linear set of tutorials that the user can follow, each with links
to the relevant KB entries. Give them proper tags and add 'Keep in mind'
sections to reinforce the important takeaways at the end of each."
Following AGENTS.md and WORKFLOW.md your agent will scaffold a structured knowledge base that you can open with Obsidian, and your agent can manage with wiki.
So, who needs a wiki CLI?
Still not the tmux wizard. Still not you. But past a dozen files, your agent most likely does.
Your agent brings the judgment, the tool brings the determinism. Neither alone is the trick; the two together are.
The tool is available at github.com/agentic-wiki/wiki and the skills are at github.com/agentic-wiki/skills. Issues and PRs are welcome.
Top comments (0)