Every Omni model has an AI context problem eventually. Someone asks a normal question, the agent picks the wrong field, and you realize your context is stale — because it was written once, by hand, and nobody’s touched it since. I wanted to show a different way to keep it current: treat ai_context like code, and let Claude Code write and maintain it for you — not just from a doc you drag in once, but from the stuff that’s already flowing through your business.
Most teams write ai_context the same way they write a README: once, at launch, then never again. But the things that should inform it — your data dictionary, your support docs, what customers actually call things on sales calls — those change constantly. A metric’s definition changes. You discover an additional metric that’s now out of date. You add a new order status, or your clients start calling an existing one something different. All of that needs to stay in sync, or the agent’s answers quietly drift out of date.
The setup
First, install the Omni CLI in your terminal. Homebrew is the fastest path, but you can also install the script or download a pre-built binary from GitHub if that’s your preferred option.
Homebrew install:
brew tap exploreomni/tap
brew install omni
Once the CLI is installed, install the Claude Code plugin:
/plugin marketplace add exploreomni/omni-agent-skills
/plugin install omni-analytics@omni-analytics
From Claude Code, this gives you the omni-modeler subagent — direct, validated access to your semantic model. It can read views, topics, and fields, propose YAML edits, and check them against Omni’s model validator before anything gets synced. That’s the part that matters most: it’s not a chatbot suggesting text for you to copy-paste. It’s an agent that opens a branch, writes the change, and shows you the diff while having the Omni documentation and best practices ingrained. That’s the mechanism. The real question is what you point it at.
Starting with a file you already have
The obvious source is a doc you already have — a data dictionary, a Wiki export, a schema readme. In my case, a markdown readme with information about our tables, views, and some terminology notes for the Order Transactions topic (order_items joined to users, inventory_items, and products).
I dropped the file into Claude Code and asked it to reconcile the model against it — generate AI context based on the markdown file, scoped to the right model, topic, views and fields. Then I let it run.
Claude opened a branch — call it the markdown AI context branch — and:
- Added and adapted AI context on the
order_itemstopic based on what was in the markdown file - Added field descriptions across the different views, including things like the
userssignup address fields - Flagged the
emailfield as PII and handled it accordingly rather than surfacing it as a plain describable field
That last point is worth calling out on its own.
A quick note on PII
One thing I didn’t explicitly ask for, but appreciated: Claude noticed email was personally identifiable information and corrected how it was described and referenced rather than just parroting the field back verbatim. Same rule as any AI-generated model change — read the diff before merging — but this is exactly the kind of thing worth double-checking specifically, not just checking for validation errors.
Back in Omni, I could see the markdown AI context branch, and checking the diff showed exactly what changed: AI fields added or adapted, the signup address and other context pulled in from the markdown file, and additional field-level descriptions across views. One file, one pass, done.
Going beyond day one: point Claude Code at a source, not a snapshot
The file-upload case solves day one. It doesn’t solve the ongoing problem — your data dictionary isn’t static. Someone renames a field, adds a caveat, or a metric gets duplicated. So instead of a one-time drag-and-drop, the second half of this was about pointing Claude Code at a source, not a snapshot.
I used our Order Transactions data dictionary in Notion — a page our data team keeps continuously updated. Recently it had picked up a couple of small, realistic edits: sale_price got new synonyms (“amount paid,” “revenue”), and a new order status, On Hold, showed up in the list of values.
Back in Claude Code, the prompt was roughly: pull the Notion data dictionary page via its API on a schedule (weekly, in this case — could just as easily be nightly, or triggered by a webhook when the page is edited), feed the new version plus the previous version in, and update the affected topics’ AI context accordingly, on a new branch. This opens a branch, makes the edit, runs validation, and — if GitHub is enabled — opens a pull request for someone to review before merging. You’ve turned a manual chore into a diff someone approves in thirty seconds.
What Claude Code actually built
Rather than just making the one-time edit, Claude Code set up a recurring routine — a weekly automation, running every Monday morning, that:
- Fetches the Notion page fresh, with no caching
- Diffs it against the current AI-context branch’s topic YAML
- Skips the write entirely if nothing changed
- Re-verifies any new or changed enumeration values (like a new status) against the live data before trusting them
- Always reapplies the PII exclusion, so a future sync can’t accidentally undo it
- Writes to the same branch and validates it, but never merges to production automatically
That last point is the safeguard: everything lands on a branch you can review at your own pace. You get the pull request, you check it, and if you’re happy, you merge — done in about thirty seconds of review, not thirty minutes of manual editing.
Checking Omni Preview afterward, I could see the new Notion AI context branch on the order_items topic, with the AI context updated and a handful of description changes on the users view as well.
The pattern here is the same as any docs-as-code pipeline — the only difference is that the target is your semantic model instead of a website. Notion is a good example, but the same approach works against Confluence or any other company wiki that changes continuously.
What’s next: same mechanism, different inputs
There’s a third input worth calling out: call transcripts. If customers are asking support or sales questions using unexpected or different terminology, that’s exactly what should get baked into your synonyms, or general ai_context — and it’s sitting in your call recordings rather than in any doc.
Same mechanism throughout — CLI-backed, validated, reviewable — just different inputs: a file you already have, a doc that keeps changing, and the conversations happening around your data every day. Treat your context layer like code, and it stops going stale.
Check out the video to see it live: Keep Omni AI Context Updated Programmatically
Thanks for reading, and see you soon.