Supercharging Your Harness: Skills, Rules and MCP with Google Antigravity
The harness I’ve been hand-writing is now a set of first-class primitives — and here’s where you maximise your (team) know-how moat.
Supercharging Your Harness: Skills, Rules and MCP with Google Antigravity
The harness I’ve been hand-writing is now a set of first-class primitives — and here’s where you maximise your (team) know-how moat.

Random Promots, tools, scripts, not get organised in a neat cohernet collection of skills, rules and tools, to help you achieve consistency of build outcomes
I’ve battle-tested for two years that the Harness is the core of a working agent, not only the model than ran at a time. Antigravity turns that argument into primitives. Here’s what I built in the lab, and what it changes for your team.
If you’ve read anything I’ve put out under #HarnessEngineering, you already know the one-liner: the model is the easy, commoditised part. The durable engineering lives in the scaffolding you wrap around it — the rule files, the tools and MCP servers, the sandboxes, the orchestration, the hooks, the evals.
Google’s 2026 SDLC paper — *“The New SDLC With Vibe Coding”*, from Addy Osmani, Shubham Saboo and Sokratis Kartakis — puts the model at roughly 10% of a working agent and the harness at the other 90%. From the field I’d call it closer to 35:65 — argue the exact number over a coffee, either way the harness wins. Most “the agent is broken” moments I see aren’t model failures at all. They’re configuration failures: a missing tool, a vague rule, a guardrail that was never written, a context window stuffed with noise.
Back in December I hand-rolled that whole argument into a shipping product — the C4X extension, built end-to-end with Gemini 3 and Antigravity in about a week. A GEMINI.md as the rules for future AIs. Nine phases. 450+ tests as the safety harness I ran myself, to check the model wasn't telling me porky pies. 🧾 It worked because the foundation was mine, and the model just filled the middle.

between vscode marketplace and vsx org — there are 6k users using my now

Then I open-sourced the pattern: ai-native-developer-experience — an opinionated DX harness, two years of building, breaking and fixing, distilled into one place. Speed is easy. Safe speed is engineered.
So when I sat down with the latest Antigravity challenge lab this week, the thing that jumped out wasn’t the demo. It was this: the harness I’ve been hand-writing is now a set of first-class primitives.
The Coding Lab Tests
The scenario i fully validated this experimented as a handy is a winter storm hammering an online retailer’s shipping, and a surge of angry customers behind it.

One of many labs to try on Google Training site
But there are many other great labs on **Skills.Google.com**
Build an agent that triages the disrupted orders — look up status, check the customer’s loyalty tier, issue the right compensation, draft the reply. Standard enterprise mess. What matters is how you assemble it.
Three things I used to write by hand are now shipped in the box.
Rules. A GEMINI.md at the workspace root, always-on, enforcing the standards every file has to meet — docstring at the top, copyright header, where skills are allowed to live. This is the exact "prompting rules for future AIs" idea I shipped in C4X, except now the IDE treats it as a contract it enforces, not a convention I hope the model remembers. The rule underneath all of it is the one I keep repeating on delivery: if it's not in the repo, the agent doesn't know.

Skills. A SKILL.md that encodes the actual operating procedure — verify the order, read the loyalty tier, apply the compensation matrix (Platinum gets a $100 credit and a Next-Day Air upgrade, Gold gets $50, Silver $25, and so on), then draft an empathetic customer reply. Read that again. The business judgment — who gets what, and why — lives in a versioned, reviewable file, instead of being buried in a prompt or walking out the door in someone's head.

MCP. The agent never touches the database directly. It reaches the logistics data through an MCP server — a governed seam where you decide exactly which tools (get_order_status, get_customer_loyalty_info, issue_disruption_compensation) the agent is allowed to call. Point it at BigQuery, Spanner, AlloyDB, Cloud SQL — the agent inherits a contract, not a connection string.

And when you deploy to Agent Runtime, the agent gets its own identity: a principal that starts with zero access until you grant it, least-privilege by default. The governance is the first thing you configure.

ADK Trace
Where the moat moves
Here’s the part worth sitting with. When the platform ships the harness as primitives, the mechanics stop being the differentiator. Anyone can scaffold Rules, Skills and an MCP config now.
The **agents-cli **writes the boilerplate for you and deploys it.

So where does the advantage go? Up. Into the SKILL.md. That compensation matrix is encoded judgment — it's what a good operations SME knows about keeping a Platinum customer through a bad week, written down where a team can review it. The moat was never the plumbing. It's the domain SOP you put inside the plumbing, the shared context your team agrees on, the definition of done you're willing to enforce.
Which is exactly why I keep saying the unit of delivery is shifting to the SME who owns a squad of agents. AI cannot be held accountable. The agents do the work; a human still owns the judgment, the risk, and the consequence. So the human isn’t writing the loops anymore. They’re writing the rules the loops obey and the skills the loops run. That’s a more senior job, not a smaller one.
How to get the good outcome (and not a demo that dies in production)
A few things from the field, if you want value and not a science project:
- Design before you generate. I spent hours on constraints before C4X wrote a line. The lab rewards the same move: rules and skills first, code second. The AI is only ever as good as the constraints you give it.
- Put the judgment in a skill. If a decision touches money, compliance, or customer trust, it belongs in a reviewable
SKILL.mdyour team can argue over, not a throwaway prompt nobody version-controls. - Treat MCP as a boundary, not a pipe. The value isn’t “the agent can reach the database.” It’s “the agent can only do these four things to it.”
- Configure identity first. An agent that starts with zero access and earns each grant is the difference between a governed system and next quarter’s incident review.
- Keep the evals in view. Traces, token counts, latency per step — you get them in the playground for free. That visibility is what turns a prototype into something you’ll actually run at 3am.
Next?
This is all available for you, Today, to get started with. The abstractions I was hand-writing in December are mere buttons in the Antigravity IDE today.
So the question for you and your team is not whether “can we build a harness or not, and how”.
It’s “whose judgment goes (gets codified) into Your, and your Team Harness.”
PS My opinionated version lives here — rules, skills and all. Fork it, argue with it, make it yours. Borrow the patterns. Your mileage may vary.
Rinse and repeat. 🚀
Building agents, platform engineering, or agentic ways of working in the enterprise? Let’s connect — LinkedIn.
메타데이터
- post_id
- d2142e61c4fd
- slug
- supercharging-your-harness-skills-rules-and-mcp-with-google-antigravity-d2142e61c4fd
- url
- https://itnext.io/supercharging-your-harness-skills-rules-and-mcp-with-google-antigravity-d2142e61c4fd
- canonical_url
- https://itnext.io/supercharging-your-harness-skills-rules-and-mcp-with-google-antigravity-d2142e61c4fd
- author_url
- https://medium.com/@jaroslav-pantsjoha
- status
- ok
- fetched_at
- 2026-07-10 12:09:34