Spend enough time with Google Antigravity and a pattern emerges: most "why does the agent behave this way?" questions reduce, in the end, to classical information-science problems — weighting evidence, pruning candidates, modeling probability distributions over decisions.
This perspective came together for me while reading a recent math book by Jujun Furushima (Self-Taught Mathematical Thinking), which builds a continuous curriculum from Google's TF-IDF through recommendations, image classification, and generative AI. AI agent design benefits enormously from being read through this same lens, instead of through the surface lens of "how should I phrase the prompt?"
This post uses Antigravity's Architect/Builder split as the case study, reframing agent design through the language of mathematical thinking.
Architect / Builder is a candidate-pruning pipeline
Antigravity's Architect handles requirements and design; the Builder implements. Treating this as more than role separation — viewing it as an information pruning pipeline — makes the whole picture click.
User requests arrive as fuzzy natural language. "I want a login feature." From the universe of possible implementations, the Architect prunes down to a concrete spec. The Builder then prunes from the universe of possible code to a specific diff.
Mathematically, this is a candidate-reduction algorithm, the same shape as a search engine selecting ten pages out of ten billion. The only difference is that the ranking function isn't TF-IDF or PageRank — it's Gemini-class inference.
The reason this view pays off: when an Architect output looks wrong, you can locate which step in the pruning pipeline failed. Was the requirement too vague, leaving the candidate space too broad? Was context too thin to let the ranking function operate? With this framing, prompt improvements become deliberate rather than guesswork.
Two TF-IDF lessons that translate directly to context design
TF-IDF (Term Frequency–Inverse Document Frequency) is the classical word-importance model behind early search engines. The intuition: a word that appears often in a document is important, unless it appears in every document — in which case it's not.
Two lessons carry over to agent design:
Repetition is counterproductive. Writing "absolutely make sure to..." or "always..." over and over makes those words frequent across the document, lowering their TF-IDF importance. Stating a critical constraint once or twice — clearly — concentrates attention better than restating it five different ways.
Rare words carry more signal. Domain-specific terms like "our system has a strict zoning constraint" elicit strong responses from the agent. Generic words — "properly," "well," "appropriately" — carry virtually no IDF weight and don't communicate constraints.
My personal rule for Architect prompts: one specific technical term is worth more than one vague Japanese sentence. That's TF-IDF-style information design, applied to natural-language prompting.
What classification problems teach us about specifying error cases
In machine learning, the balance of positive and negative examples drastically affects classifier performance. Train without negatives and you get a classifier that calls everything positive.
The exact same failure mode shows up in AI agent prompts. "Please do X" alone biases the agent toward "always do something." Without explicit failure cases or forbidden behaviors, the agent has no decision boundary — and tends to act in unexpected ways.
Concretely, every Architect prompt I write has this structure:
- What to do (positive examples)
- What good output looks like (refined positives)
- What decisions are forbidden (negatives)
- How much autonomy is granted (boundaries)
The negatives and boundaries are the most important safety mechanism against agent runaway. In ML terms, this is "explicit decision boundary specification" — basic classification theory applied to prompt design.
What probabilistic inference teaches us about uncertainty
Modern probabilistic models emphasize working with full distributions rather than point estimates. Collapse to a single most-likely value and you lose all information about how confident the model actually is.
Same idea for agent prompts. Asking "give me the best solution" gets one answer, but no confidence signal. Asking "give me the top three options with their tradeoffs" surfaces the distribution and gives you, the human, room to judge.
A template I use for Architect when designing new features:
Requirement: enable users to log in.
Output format:
1. Top three options (OAuth/JWT/sessions/etc.).
2. For each: pros, cons, and estimated implementation effort.
3. Which fits our stack (Cloudflare Workers + KV) best.
4. Confidence level for the recommendation (high/medium/low),
plus what additional info you'd need if it's low.
Asking explicitly for confidence is quietly powerful. The agent starts asking clarifying questions when uncertainty is high, rather than barreling into an implementation while still uncertain.
Builder prompts benefit from constrained optimization framing
When the Architect hands a design to the Builder for implementation, treat the prompt as a constrained optimization problem.
A mathematical optimization is defined by an objective function (what to maximize) plus constraints (what must hold). Frame Builder prompts the same way and outputs become much more stable:
Objective: implement the login feature.
Constraints:
1. Must reuse the existing handleAuth() function.
2. Must not change the KV namespace structure.
3. Must keep test coverage at or above 80%.
4. Must complete in under 50ms of Worker CPU time.
Now the Builder isn't just writing "code that works" — it's writing code that satisfies all constraints while pursuing the objective. Leave constraints vague and the Builder tends to pick the cheapest implementation, which often means breaking your existing structure.
Three places mathematical thinking pays off
Distilled, here are the three situations where mathematical thinking has the largest impact on Antigravity agent design:
Diagnosing unexpected behavior. Instead of "let me try changing the prompt," ask structural questions: where did pruning fail? Are the negatives missing? Did I ask for confidence? You get repeatable improvements rather than guesses.
Designing multi-agent compositions. Beyond Architect → Builder, when you add reviewer / test-generator / debugger stages, defining each stage as a pruning operation on an information space makes responsibilities concrete.
Designing agent evaluations. Subjective "does it work?" judgments are noisy. Ground evaluations in classifier-style metrics — accuracy, F-score, recall against a reference dataset — and improvement becomes quantifiable.
Closing thought: math is a language
"Mathematical thinking" sounds intimidating, but the essence is simple: it's the language for asking "structurally, what kind of problem is this?" about fuzzy phenomena.
Since I started bringing math into agent design, my prompt iteration shifted from trial-and-error to theory-driven. Instead of "let me change the prompt," I now think "this word's TF-IDF weight is too low — drop it" or "I haven't specified the negative class yet."
If you take one thing away, pick one Architect prompt you wrote recently and reread it through the three lenses: information pruning, positives vs. negatives, constrained optimization. You'll find concrete things to improve. That's where mathematical thinking about agent design starts paying off.