Made with Gemini AI

AntiGravity and the Coda MCP

Two Layers, One System

Earlier in this series — back when I first started working with AntiGravity and the Coda MCP — I wrote about correcting the same basic mistakes session after session. That post was the beginning of understanding why structured rules files matter. The index file post came later — a lean map that tells an agent what skill files exist, where they live, and what they cover. That argument was deliberately framework-agnostic. This one is not. This one is about how the index file actually lands inside AntiGravity — and about the two-layer system that makes it work.

Two buttons, two different jobs

If you open AntiGravity’s Customizations panel and click the Rules tab, you see two buttons: + Global and + Workspace. They look like variants of the same thing. They are not.

steps in AntiGravity

+ Global opens — or creates — a single file called GEMINI.md, stored at the root of your .gemini folder on your hard drive. Whatever you put in that file applies to every workspace you open, every session you start. The project you have open makes no difference. It is a standing instruction that travels with you.

+ Workspace is different. It attaches rules to the specific folder you have open at that moment. When AntiGravity starts a session in that workspace, it reads the workspace rules on top of the global ones. The global layer is always present. The workspace layer adds what that particular context requires.

Global & Workspace

This is an architectural decision, not a UI detail. Getting it right is what avoids the repeated corrections I described in that first post.

If you have been working with AI through a chat interface — Claude, ChatGPT, Gemini — you already know the ceiling. A Claude Project or a Gemini Gem gets you closer: instructions and files that load before the conversation starts. Not zero anymore. But still manual, still static, still limited to whatever you remembered to add. No file system access means no path the agent can follow on its own.

AntiGravity sits in a different category. It is a VS Code extension — Gemini running as an agent directly inside your development environment, not a browser tab you open and close. Full access to your file system. That is what makes the two-layer setup possible — and what makes the rest of this post worth reading if you are used to working in a chat interface.

Where the index file belongs

When you start a session, it does not open a blank conversation. It first reads whatever rules files you have configured, loads that context into the model, and only then waits for your first instruction. That reading sequence is the mechanism everything else depends on.

In our setup, AntiGravity works in combination with the Coda MCP. The distinction between the two is worth being precise about: AntiGravity reads the rules and reasons. The Coda MCP executes — it is the connection that gives the agent hands inside your Coda Doc. One thinks. The other acts. That division is why the global layer needs to carry two things.

Two files sit at the centre of that sequence. GEMINI.md is created by AntiGravity — the global rules file, named and placed by the tool itself, not something you configure. CODA_INDEX.md is your file — the index you build and maintain for all Coda-related work. GEMINI.md exists to point to it.

The distinction matters more than it looks. GEMINI.md is a behaviour instruction — it tells the agent what to do. CODA_INDEX.md is a knowledge map — it tells the agent what Coda skill files exist and where to find them. One controls the agent. The other informs it. You could technically put the full index content inside GEMINI.md and skip the separate file entirely. But GEMINI.md loads in full every session regardless of the task. The moment the index lives inside it, every session carries the full library map as permanent overhead — even when the task only needs one skill file. With twelve skill files that is a minor inefficiency. At thirty it becomes noise the agent has to work through before it reaches your first instruction. The separation is how the system stays lean as the library grows.

That separation also means you are not limited to one index. GEMINI.md can point to as many index files as your setup requires — one per domain, each focused on its own concern. CODA_INDEX.md covers everything Coda-specific: the architecture skill file, the formula skill file, the UI standards, the audit checklist. If you work with other MCPs alongside Coda, the same logic applies. A GitHub MCP benefits from its own index covering branching conventions, commit standards, and PR templates. A Notion MCP warrants an index for its own page structure and database conventions. A Linear MCP might carry an index of issue triage rules and priority definitions. Each index covers one environment. GEMINI.md knows they all exist and points to the right one based on what the task requires.

The index file belongs in the global layer because it needs to be read before the agent knows which workspace it is in, before it knows which skill files are relevant, before it has any task-specific context at all. Not because it contains universal instructions — it mostly does not. But because timing is everything here.

The index is the first thing the agent should load. GEMINI.md is the first thing AntiGravity reads. The order is the system.

In practice, GEMINI.md carries two things. First, pointers to the relevant indexes — in our case CODA_INDEX.md for all Coda work, with room for others as the setup grows.

Before any Coda-related task, read CODA_INDEX.md. 
It maps the available Coda skill files. Use it to 
decide which files to load before starting work.

Second, the MCP constraint list — the hard limits on what the Coda MCP can and cannot execute, regardless of which client or Doc is in scope. Page width Full cannot be set programmatically and requires manual intervention. @mentions are UI-only and need manual wiring after the agent completes its work. These are not skill file content and not workspace-specific. They apply every session, every Doc, every client. They belong in the global layer permanently.

GEMINI.md does not explain what the index contains. It does not summarise the skill files. It points. The index does the rest - one line per file, a path, a description precise enough for the agent to decide whether to load it for this task.

What the agent finds in those files is what we have been building across this series. The formula skill file carries the decisions that stop the agent from defaulting to the wrong pattern. In Why Max() beats Sort() every time I showed why reaching for Sort().Last() to find a maximum value is a list-thinking habit dressed up as a formula - and why Max() with WithName() asks the right question directly. In Why Contains() beats "=" every time the same argument runs one level up: = is the right operator until either side stops being a scalar, and the agent will not know the difference without being told. In Beyond the List in Coda the shift from list thinking to set thinking becomes the architectural principle underneath both of those choices. All of that is formula standard content - not general Coda advice, but specific decisions the agent needs before it touches a formula bar.

The architecture skill file carries the structural rules: DB prefix on every base table, Name as the display column - always IfBlank() guarded - one table per page, one page per task. The UI skill file carries the page setup conventions: cover photo on, icon on, author off, callout structure fixed. None of this is exotic. As I wrote in Scaling Coda's Expertise, without those specific instructions the agent defaults to generalised patterns that blend spreadsheet logic with conventions that have no place in a well-structured Coda doc. All of it took real sessions to get wrong before it got written down.

That is what the index navigates — not abstract best practices, but documented decisions, each one traceable back to a correction.

What the workspace layer is actually for

If the global layer carries the index — and through the index, the full skill library — what is left for the workspace rules?

Two things.

First: context the agent cannot infer from skill files. Which client this is. Which Coda Doc ID the MCP should operate on. Which tables have already been built and should not be rebuilt. The Doc ID is not a small detail — with the Coda MCP active, the agent needs to know exactly which Doc it is working in before it touches anything. That is the most critical piece of workspace-specific context, and it has no business in a universal standard.

Second: workspace-specific skill files that sit outside the general library. A client with a non-standard approval flow, a Doc with edge cases the architecture skill file does not cover — those belong in a local file, referenced from the workspace rules. Not from the global index. The index stays lean. The workspace layer carries what is local.

The rule is simple enough to state in one line: if it applies everywhere, it goes global; if it applies here, it goes local. Mixing the two produces the same problem as mixing the index and the skill files — a file that tries to do too much ends up doing none of it reliably.

The same flexibility that applies to skill files applies here. Workspace files do not need to live next to the project folder. Cloud storage platforms — Google Drive, Dropbox, Microsoft OneDrive — all follow the same logic: a path the agent can reach, a file it can read. Which platform you use is a matter of preference, not architecture. GitHub is the one exception worth naming separately, not because it stores files differently, but because it adds version history — useful when a client’s workspace conventions evolve over time and you want a clear record of what changed and when.

One practical constraint: if you use a sync service, make sure the workspace file is set to always keep on this device. If the file is cloud-only and not physically on disk when the session starts, the agent goes looking and finds nothing. The layer exists but does not load. That is a silent failure — no error, just missing context.

A session in practice

When I open a client workspace in AntiGravity, the sequence is deterministic. GEMINI.md loads first — it points the agent to CODA_INDEX.md and sets the MCP constraints before anything else runs. The index loads: the agent now knows what Coda-specific files exist, what each covers, and has the core conventions already in context. Then the workspace rules load: client name, Coda doc ID, any local skill file relevant to this project.

By the time I type the first instruction, the agent already knows the architecture standards, the formula conventions — ForEach() not FormulaMap(), Max() not Sort().Last(), Contains() not = on relation columns - what the MCP cannot do, and the specifics of this client's workspace. I do not explain any of that. I describe the task.

That is what the two-layer system is built to produce: a session that starts with full context rather than one that builds context through back-and-forth. The global layer is the library. The workspace layer is the briefing. Together they are the agent’s preparation before the work begins.

The one thing that breaks it

The system fails in exactly one way: when context bleeds across layers.

A global rules file that lists client names is already wrong. A workspace rules file that re-states formula conventions is redundant at best, contradictory at worst — because the next time you update the skill file, the workspace copy stays stale. The agent then has two sources of truth for the same rule, and no reliable way to know which one is current.

Keep the layers clean. The global layer points to the right index for the task, carries the MCP constraints, and nothing more. The workspace layer carries what is local and nothing beyond that. That discipline is what makes the two-layer system scale — not as a configuration exercise you do once, but as a habit you maintain every time you add a file or start a new client engagement.

What comes next

AntiGravity is one half of the setup I work with. Claude is the other — but “Claude” is not one thing. There are three surfaces, they do not all work the same way, and only one of them is a genuine peer to AntiGravity. That is where the next post starts.

On a personal note, creating these in-depth posts takes a lot of time and effort. While I love sharing my knowledge, a little support goes a long way. If you found this helpful, consider a small donation. Every bit of encouragement helps fuel the next deep-dives!

My name is Christiaan, and I regularly blog about Coda. If you’d like to take this further with hands-on support for your own Coda setup, I offer professional consultations — feel free to reach out. You can also find my free contributions in the Coda Community and on X. The Coda Community is a fantastic resource for free insights, especially when you share a sample doc.