Insights

Keeping Multiple AI Agents Consistent with SSOT for Paths and Tokens

8 min read#ssot#claude-code#codex#environment-variables#ai-agents

Who this is forSolo developers and operators who run several AI agents such as Claude Code and Codex and want their paths, IDs, and tokens to stay consistent.

When you run several AI agents against the same tools, they stop agreeing with each other without telling you. Claude Code, Codex, and automation scripts each remember the same fact with a different value, and integrations break one at a time. The error rarely points to the real cause. This article describes the fix I use: a single source of truth (SSOT) for each kind of information, with every other file holding only a pointer to it. The method is simple enough for a laptop with a handful of AI tools, and it decides how long the setup keeps working.

Why the environment breaks

I connect more than 10 tools to AI agents, including Notion, Google Workspace, Obsidian, n8n, and Supabase. When that happens, the same piece of information spreads across several files. For example:

  • The Obsidian vault path is written as ~/Documents/Obsidian Vault in one file and as iCloud~md~obsidian/... in another.
  • The Supabase project list appears in CLAUDE.md, in CLAUDE.local.md, and in an environment map document.
  • A document still refers to a ghost script (scripts/notion-find-db.mjs), but the file no longer exists.

I hit three incidents because of this. Each one had the same root cause, and each one is listed below.

Incident Cause Symptom
Work log saved to the wrong path The vault path was written differently in each document A day’s entries piled up in the iCloud backup folder
AI agent called a script that does not exist The “verification command” in a document pointed to a script removed long ago Every session started with “file not found”
Supabase project name did not match reality Three documents each held a list from a different point in time The CLI connection failed because of a wrong reference ID

All three share one cause: the same fact was written down in several places. Once information is scattered, one copy always gets old first. Later, whoever reads it, whether that is me or an AI agent, cannot tell which value is correct.

The SSOT principle

SSOT stands for Single Source of Truth. The rules are simple:

  1. Each piece of information lives in one file only.
  2. When another file needs that information, it keeps only a pointer, meaning a path or a link.
  3. Following the pointer always leads to the original.

An analogy: a company does not maintain its org chart separately in every department. HR keeps the only copy, and other departments simply write “the latest version is on the HR shared drive.”

A three-layer architecture by information type

For a solo operator’s AI setup, information falls into three broad types. Different types need different storage locations.

Layer Information type Examples Storage location (my implementation)
1. Secrets Tokens and API keys Notion API key, Supabase token Shell environment file (~/.zshenv)
2. Structural constants Paths, IDs, project lists Obsidian vault path, Supabase project list, calendar ID Agent-neutral document (AGENT_GUIDE.md)
3. Agent rules Behavior instructions (“work this way”) Stop after three failures; check conditions before delegating Operating rules section of the layer 2 document

Principles for each layer

  • Layer 1 (secrets): keep it in one file. Do not copy it into a per-project .env. AI agents run as child processes, so they inherit shell environment variables automatically.
  • Layer 2 (structural constants): keep it agent-neutral. Put it in a shared folder that any agent can read, not in a Claude-specific folder such as ~/.claude/.
  • Layer 3 (agent rules): place only rules that must differ by agent in that agent’s own folder. Everything else, such as safety rules for reorganizing files or verification before experiments, goes in layer 2.

Bridge layer: letting several AIs read the same source

Claude Code and Codex read different default files.

AI agent Files read by default
Claude Code ~/CLAUDE.md, ~/.claude/rules/*.md, ~/.claude/skills/
Codex CLI ~/AGENTS.md, ~/.codex/

Because of this difference, information stored only in a Claude-specific folder is invisible to Codex. The reverse is also true.

The fix is a bridge file. Each agent’s default file contains only a pointer to the SSOT, and the actual content lives in an agent-neutral file. The structure looks like this:

[SSOT layer — shared by all agents]
  ~/.zshenv                            ← secrets
  ~/Projects/shared/AGENT_GUIDE.md     ← structural constants · operating rules

[Bridge layer — each agent points to the SSOT]
  ~/CLAUDE.md    → "import AGENT_GUIDE"
  ~/AGENTS.md    → "see AGENT_GUIDE"

[Agent-specific — behavior rules only, no shared data]
  ~/.claude/rules/
  ~/.codex/rules/

With this layout, environment information that Claude updates is immediately readable by Codex, and both agents work from the same paths, IDs, and rules.

Real file map: what goes where

This is the actual layout in my workspace.

Information Location Reason
Notion, Supabase, Gemini, and Obsidian API keys ~/.zshenv Shell environment variable, inherited by every child process
Obsidian vault path AGENT_GUIDE.md section 11 + OBSIDIAN_VAULT_PATH environment variable People, scripts, and AI all reference the same value
Supabase project list AGENT_GUIDE.md section 5 Previously copied to three places and drifted; consolidated into one
Notion DB IDs ~/Projects/shared/notion-db-registry.md IDs change often, so they get a separate reference table
Work log calendar ID AGENT_GUIDE.md section 11 Referenced by automation scripts
retry budget, dry-run, Codex delegation prerequisites AGENT_GUIDE.md section 12 Agent-neutral rules
Python virtual environment policy (uv required) AGENT_GUIDE.md section 12 Both agents set up environments the same way

The main point: layers 1 and 2 hold the values. Bridge files and agent-specific folders hold only pointers.

Maintenance rules

Cleaning up once is not enough. Some everyday rules keep the SSOT from breaking:

  1. When new information appears, first ask which layer it belongs to. Once the layer is clear, the location is clear.
  2. Use pointers instead of copies. “See that section over there” always beats a copy.
  3. Before creating a new file, consider adding to AGENT_GUIDE first. Small notes pile up and become the source of drift.
  4. Search for ghost references regularly. Check once a month with grep that every file or script a document mentions still exists.

Why this matters for solo operators

Large companies assign people to organize documents. A solo operator has no such staff. AI agents can take on that role, but an AI that does not know where information lives will rely on memory and invent values. That invention is one of the real causes of hallucination.

An SSOT reduces hallucination structurally. If an agent is told to read a specific file before relying on memory, and that file is the single original, there is much less room for the agent to make something up.

The same structure explains why a system built by following a guide keeps working over time. If this were taught in a book aimed at solo operators and beginners to workflow automation, I would introduce it in three steps:

  1. Early: create one “environment map” file that holds paths, IDs, and project lists in one place.
  2. Middle: put API keys in shell environment variables, with one working example.
  3. Late: when adding a second AI agent such as Codex, show how to create a bridge file.

Showing a structure that starts small and grows lets beginners follow along.

Presentation angle

If I presented this at Data Yanolja, a Korean data conference, the audience would be developers and data practitioners, so I could use a more technical lens:

  • Possible title: “MLOps for One Person: A Configuration File Strategy for People Who Run Several AI Agents”
  • Core message: the principles of config management and feature stores in production apply to individual workers too.
  • Differentiator: the context is not company infrastructure but “one laptop and four to five AI tools.”

Social post drafts

LinkedIn draft (translated):

I have been using Claude Code and Codex together, and I hit three incidents where the two AIs remembered the same fact with different values.

In one, a work log was saved to the wrong folder. In another, an AI kept calling a script I had already deleted. In the third, a Supabase project name differed between documents and the connection failed.

The cause was the same every time. The same information had been copied into several files, and over time one copy aged.

To fix this, I reorganized my environment around the SSOT (Single Source of Truth) principle:

  1. Secrets (API keys) live in one shell environment file.
  2. Structural constants (paths, IDs, project lists) live in one agent-neutral document.
  3. The default config files for Claude and Codex contain only pointers to that document.

Now, when one AI changes the environment, the other reads the same source, and I no longer have to explain to it where a ghost script path should be fixed. I also put operating rules, such as “stop after three failures” and “check conditions before delegating,” in the same document so both agents work the same way.

If you use only one AI agent, you may not need this. Once you use two or more, this structure becomes necessary. If you have a better way to manage this, please share it.

Threads draft (translated):

I use several AI tools, and they remember the same information differently. One AI knows my Obsidian vault as an iCloud path. Another knows it as a Documents path. The result: work logs piled up in the wrong folder.

The cause is simple. I wrote the same value in several files. Over time, one copy gets old first. That is when hallucinations start.

The fix is also simple. Each piece of information lives in one file. Other files hold only pointers. That is SSOT.

I split it into three layers. Tokens go in the shell environment. Paths and IDs go in one agent-neutral document. Each AI’s config file only points to that document.

With one AI, you may not need this. From two AIs onward, this structure determines how long the system lasts.

Bottom line

For a setup with several AI agents, the problem is not any single tool. The problem is that the same fact gets written in several places and drifts apart. The evidence from my three incidents supports one conclusion: give each kind of information one authoritative location, keep secrets in the shell environment, keep paths, IDs, and shared rules in one agent-neutral document, and let every agent-specific file point to that document. This takes little effort to set up, and it is what keeps a multi-agent environment working as it grows.

Sources

  • My work log (session notes, April 21, 2026)
  • ~/Projects/shared/AGENT_GUIDE.md sections 2, 5, 11, and 12
  • ~/AGENTS.md (Codex bridge)
  • OpenAI Codex documentation on AGENTS.md: https://github.com/openai/codex
  • Anthropic Claude Code documentation on CLAUDE.md: https://docs.anthropic.com/en/docs/claude-code
  • Reference concept: Single Source of Truth (general software engineering term)
  • Related research note: 2026-04-21-notion-api-vs-mcp-codex-setup.md

Frequently asked questions

What is an SSOT for AI agent environments?
A single source of truth: each piece of information lives in exactly one file, and every other file holds only a pointer to it. Secrets go in ~/.zshenv, structural constants go in AGENT_GUIDE.md, and agent config files point to that guide.
Why do Claude Code and Codex need bridge files?
Claude Code reads ~/CLAUDE.md and ~/.claude/, while Codex CLI reads ~/AGENTS.md and ~/.codex/. Bridge files in those default locations point to the shared AGENT_GUIDE.md, so both agents read the same paths, IDs, and rules.