DEV Community: Code Nomi Nomi

There is no normal brain, only a majority brain

Code Nomi Nomi — Wed, 30 Sep 2026 07:43:34 +0000

Our workspaces and tools are designed for a specific cognitive profile:

On-demand sustained attention

Stable working memory

Tolerance for low-stimulation repetition

Linear prioritization

This profile is common, but it isn't the gold standard—it's a statistic.

The term "neurotypical" doesn't describe a brain that works well; it describes a brain whose functioning aligns perfectly with the implicit assumptions of its environment. Conversely, "neurodivergent" doesn't describe a broken brain, but one whose functioning mismatches those assumptions.

It is not a difference in capability. It is a difference in context fit.

The Runtime Problem
Consider a standard engineering scenario: an application crashing in production isn't necessarily bad code. It might be perfectly written, just intended for a different runtime.

No engineer would call an ARM binary "deficient" because it fails to execute on an x86 architecture. We just recognize it's on the wrong hardware. Yet, we evaluate human brains as if there were only a single valid instruction set.

What this means for tech teams
The developer who "lacks rigor" on boilerplate tasks might be the one who spots the critical architectural flaw everyone else missed.

The teammate whose ideas "go in every direction" might generate the breakthrough connection a highly structured sprint planning would have crushed.

The builder who "can't stick to the process" might simply be someone who has never had a process built for their specific architecture.

The question isn't: should we accommodate neurodivergent people?
The question is: how much innovation are we losing by forcing every profile to run on the exact same runtime?

There is no normal brain. There is a majority brain. 🧠

Code Nomi Nomi — Wed, 30 Sep 2026 07:42:53 +0000

Our work environments are designed for a very specific cognitive profile: on-demand sustained attention, stable working memory, tolerance for low-stimulation repetition, and linear prioritization.

This profile exists. It is common. But it isn't the gold standard—it's just a statistic.

👉 "Neurotypical" doesn't describe a brain that works well. It describes a brain whose functioning aligns perfectly with the implicit assumptions of its environment.
👉 "Neurodivergent" doesn't describe a broken brain. It describes a brain whose functioning does not align with those assumptions.

The difference isn't about capability. It's about context fit.

An example any engineer will understand:
An application crashing in production isn't necessarily poorly written. It might be perfectly coded, but built for a different runtime. No one would call an ARM binary "deficient" just because it won't run on an x86 architecture. We would simply say it's on the wrong machine.

Yet, we spend our professional lives evaluating human brains as if there were only one valid instruction set.

What this means in practice:
💡 The person who "lacks rigor" on repetitive tasks might be the one who spots the architectural flaw everyone else missed.
💡 The person whose mind "goes in every direction" during a meeting might be the one generating the breakthrough connection a highly structured agenda would have stifled.
💡 The person who "can't follow the process" might simply be someone who has never been given a process built for their architecture.

The debate isn't about whether we should "accommodate" neurodivergent people.
The real debate is: how much value are we losing by forcing every profile to run on the exact same runtime?

AI Visibility — what AI'Bots really read from your site

Code Nomi Nomi — Wed, 30 Sep 2026 07:24:08 +0000

Who visits your sites?

Code Nomi Nomi — Wed, 30 Sep 2026 07:21:58 +0000

AERO-KIT*- an MCP rule-verdict agent that refuses to hallucinate

Code Nomi Nomi — Sun, 20 Sep 2026 16:28:46 +0000

*This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

https://github.com/fotsopatrick/andromede

What I Built

AERO-KIT is a small, deterministic MCP agent that answers operational questions about a modular instrument (the "CTRL-7") — from a Sanity Knowledge Base structured as policyOrRule, errataOrAmendment and resolutionCase. Its job is exactly the kind a rulebook-vs-errata board-game companion faces: when two active rules contradict each other, the agent either resolves the conflict formally or refuses to answer and says why.

The rulebook says the CTRL-7 may be configured up to 75 °C. The errata says 60 °C (security override). A human arbitration record confirms 60 °C. A keyword search scores both claims as a tie and cannot decide. The agent answers 60 °C with both sources cited, the precedence relation shown (precedenceLevel 3 > 1), and the arbitration record corroborating it. And when the Knowledge Base holds two active altitude rules (2000 m vs 1500 m) with nothing to arbitrate, the agent refuses to extrapolate.

Demo

The walkable proof is the CLI session:

npm run transcript && cat TRANSCRIPT.txt

TRANSCRIPT.txt contains four resolutions (univocal, contradicted, unresolved-contradiction, out-of-KB) with the full MCP tool trace (initial_context, schema_explorer, groq_query) of each, replayed against a faithful local clone of the Context endpoint so it is byte-deterministic.

The hosted Context endpoint is live too: initialize → 200, tools/list → initial_context, groq_query, schema_explorer, array_field_reader, and the agent answers the three canonical questions against it (500 W univocal / 60 °C errata-override / altitude guard-rail refusing to extrapolate).

Code

Repository: (provide URL after push) · tags: devchallenge, sanitychallenge, sanity, ai

npm install
npm test   # tests 9 · pass 9 · fail 0

How I Used Sanity

The agent connects over MCP (Streamable HTTP) to the Sanity Context endpoint in GROQ mode and uses its four tools: initial_context to orient, schema_explorer to verify the schema before writing any query, groq_query to fetch candidate rules, amendments through the relation (targetRuleRef._ref == ...), and human arbitration records; array_field_reader for array fields.

The Knowledge Base is custom Sanity content seeded into the Content Lake: rules carry normativeValue/normativeUnit/precedenceLevel; errata carry amendedValue, a targetRuleRef relation to the rule they correct, and a higher precedenceLevel; a resolution case records authoritativeSourceRef and conflictingSources. Everything stays linked to its source (sourceUrl), so every claim in an answer carries a reference.

Without the structure — without the targetRuleRef relation and the precedence ordering — the answer is undecidable. That's what Test 3 proves.

Sanity Project Details

Sanity project ID: 3b1mty75
Dataset: production
Public dataset URL: https://3b1mty75.apicdn.sanity.io/v2026-09-20/data/query/production?query=*%5B_type%3D%3D%22policyOrRule%22%5D (verified reachable — see also the GROQ endpoint pattern in README.md)

The Knowledge Base is seeded and live: npm run seed inserted the 6 documents from scripts/seed-data.ts into 3b1mty75.production with deterministic _ids (idempotent), and a read-only GROQ check confirms count(*) == 6 with the errataOrAmendment → policyOrRule relation intact (targetRuleRef._ref == "rule-ctrl7-temp-spec"). The hosted Context MCP endpoint is live (https://api.sanity.io/v1/context/organizations/o4gse4k6t/mcp/aero-kit, GROQ mode, dataset source 3b1mty75.production, schema registry deployed, Studio app ≥ 5.1): it requires an organization API token with sanity.knowledge-base.read (Context Viewer) — verified live (a project token is refused with -32007); initialize returns 200 and tools/list serves the four tools. The server re-serializes single-quoted type literals to bare identifiers (matching 0 documents), so GROQ queries use double quotes. Every test and the CLI transcript run against a faithful local clone of the Context endpoint (same four tools, same client code path) so they are deterministic; the agent connects to the hosted endpoint through MCP_ENDPOINT_URL / MCP_ENDPOINT_TOKEN and was verified against it for the three canonical scenarios.

How We Built a Zero-Hallucination MCP Rule-Verdict Agent in 6 Hours Without Writing a Single Line of Code

Code Nomi Nomi — Sun, 20 Sep 2026 16:03:38 +0000

The Story: Zero Code, Maximum Engineering

When you participate in hackathons (and especially when you like to wrap them up in 48 hours max), the bottleneck is usually typing boilerplate, debugging weird syntax, or wrestling with unpredictable LLMs.

For this project—AERO-KIT, a deterministic MCP (Model Context Protocol) agent designed to solve complex rule contradictions using Sanity structured content—I didn't write a single line of code myself.

Instead, I acted entirely as the Chief Architect and Director. The real workforce? A meticulously orchestrated AI stack:

Gemini Chat as the core strategic brain (designing the architecture, orchestrating the execution steps, and maintaining strict technical guardrails).
OpenCode powered by Big Pickle as the local rapid-execution nano-engine, pushing out files, tests, and configurations at lightning speed.

How It Works (The Method)

Most AI agents fail at authority arbitration because they rely on fuzzy vector RAG (Retrieval-Augmented Generation). If a rulebook says 75°C and an errata says 60°C, a naive keyword search treats them as a tie and hallucinates a blended or wrong answer.

AERO-KIT solves this through structured data and rigid execution guardrails:

Sanity Content Lake as Knowledge Base: Linked types (policyOrRule, errataOrAmendment, resolutionCase) where amendments explicitly point to the rules they override via targetRuleRef and a higher precedenceLevel.
Deterministic MCP Integration: The agent connects to a Sanity Context MCP endpoint in GROQ mode.
The Guardrails / Skills Methodology: Borrowing from internal engineering standards (testComplet, fixe-de-bug, and strict anti-hallucination gates), the agent is programmed never to guess. If a contradiction isn't formally arbitrated by a higher-precedence rule or a human record, it refuses to answer and states why.

The Proof

We didn't just hope it worked. OpenCode and Gemini built a rigorous test suite (node --test) resulting in a 9/9 green test bench:

TEST 1: Univocal queries return precise normative values with Sanity ID citations.
TEST 2: Contradictions are formally resolved using precedence levels (3 > 1).
TEST 3 (Anti-RAG): Proves that text-only search fails while structured graph traversal wins.
TEST 4 (Guard-rails): Guarantees zero hallucinations and correct handling of out-of-bounds or ambiguous questions.

Every execution creates a verifiable CLI session transcript (TRANSCRIPT.txt) proving that tools like initial_context, schema_explorer, and groq_query were actually utilized.

What We Learned

Architecture beats parameter size: You don't need a massive, expensive cloud model to build sophisticated software. A fast, lightweight local nano-engine guided by precise procedural skills (testComplet) outperforms an unguided frontier model any day.
Prompt-driven development is real engineering: Directing an agent like an engineering team leader—giving it strict error boundaries, mandatory test-driven validation, and zero-tolerance policies for hallucinations—turns AI into a true force multiplier.

Built with Gemini Chat, OpenCode (Big Pickle), and Sanity. Because great engineering is about orchestrating systems, not fighting syntax.

Why 86% of an AI agent's decisions shouldn't touch an LLM

Code Nomi Nomi — Sun, 20 Sep 2026 06:34:03 +0000

Breaking down our local architecture routing 86% deterministic code, 11% SQLite, and 3% LLM on an i7-7700 with 0€ monthly API costs.

https://alice.matourdecontrole.fr

In an autonomous agent system, most decisions are not speculative[cite: 10]:

Is this action permitted[cite: 10]?
Does this database record exist[cite: 10]?
Is this field mapped[cite: 10]?
Did the unit test pass[cite: 10]?

Defaulting these checks to a remote language model introduces network latency, recurring API costs, and probabilistic drift[cite: 10].

In our architecture (Alice), we inverted the execution pipeline[cite: 10]: deterministic logic resolves first, local memory follows, and the language model is called strictly as a fallback[cite: 10].

The Request Breakdown

Here is the empirical split measured across live workloads[cite: 10]:

86% — Handled directly by code (0.23 s · 0 € · 0 LLM calls): Deterministic gates, regex, and state machine transitions resolve the vast majority of operations instantly[cite: 10].
11% — Resolved via local memory (0.65 s · local SQLite): Retrieved from an indexed store of 9,153 passages[cite: 10].
3% — The LLM layer: Reserved exclusively for open-ended or novel inputs that local rules cannot arbitrate[cite: 10].

Running at 0 € / Month on 2017 Hardware

The entire system operates on a commodity host (Intel Core i7-7700, 8 GB RAM)[cite: 10]:

No external API dependency: 0 € monthly billing[cite: 10].
Sovereign storage: LUKS-encrypted, zero bytes leave the machine[cite: 10].
Reliability: 56 TDD unit tests passing green[cite: 10].

Two deterministic guards sit in front of the model layer[cite: 10]:

A guard that explicitly refuses to process queries outside its verified context[cite: 10].
A math/execution router that delegates calculation directly to runtime logic rather than token generation[cite: 10].

If the network drops, the system degrades gracefully: the remaining 3% slows down, but the core 86% continues to execute without interruption[cite: 10].

Question

When building production agents on sensitive or private data, how do you segment deterministic code vs. model inference? Do you handle routing through an FSM, or do you still pass control flow to the prompt layer?

Why the LLM that says "I don't know" won our benchmark (and why it took 163 ms longer)

Code Nomi Nomi — Sun, 20 Sep 2026 06:24:07 +0000

We tested 5 LLMs on negative constraints and traps. Here is what we learned about silent empty responses, latency, and deterministic refusal.
https://arthur.matourdecontrole.fr/

Choosing a language model for production pipelines today usually feels like a gamble: vendor-reported latencies, irrelevant leaderboard scores, and an overwhelming halo effect around the newest flagship release[cite: 7].

When designing an autonomous agent system, the priority changes[cite: 7]. An agent doesn't need to write Shakespeare; it needs to be reliable. A confident hallucination costs significantly more than a refusal or a silence.[cite: 7]

We ran a benchmark with a simple premise: test models on their ability to handle constraints they cannot fulfill[cite: 7].

Here is what we observed, the architectural traps we hit, and the metrics recorded on our local benchmark[cite: 7].

The Protocol: Three Tests, Zero Mercy

We evaluated five setups (including DeepSeek, local Qwen 2.5-3B, and Gemini 2.5 Pro) across three distinct workloads[cite: 7, 9]:

A simple classification task (structural extraction)[cite: 7].
A pure mathematical calculation[cite: 7].
An information trap: a prompt where the only objectively correct answer is "I don't know" or "I cannot determine this"[cite: 7].

When facing the trap, most generalist models attempt to invent plausible context with complete confidence[cite: 7]. They fill the void rather than declaring missing context[cite: 7].

Finding #1: The Silent Empty Response Bug

During stress testing, one model consistently returned completely blank responses ("") without throwing any standard API error code[cite: 7].

The cause: When the output constraint (max_tokens) is set too low for an instruction-tuned model that tries to write verbose reasoning, it aborts output generation entirely if it cannot close its tokens cleanly[cite: 7].
The impact: The caller script received a HTTP 200 with an empty payload[cite: 7]. In an agent pipeline expecting structured data, the parser broke with zero debugging signals[cite: 7].

Operational lesson: Never assume a model will naturally trim its answer[cite: 7]. You must explicitly configure strict token ceilings alongside fallback handlers for zero-byte payloads[cite: 7].

Finding #2: The Concision Ceiling

Without strict limits on output length (max_tokens clamped tight) and an explicit constraint on token concision, instruction-following degrades rapidly on negative constraints[cite: 7, 9].

The moment a model is allowed to output verbose Markdown or explain why it is processing the prompt, its attention drifts away from negative instructions (e.g., "Do NOT invent missing details"). Enforcing a minimal output length directly improved negative constraint adherence across the board[cite: 7, 9].

Benchmark Results (Measured Run)

Recorded on an isolated test machine (metrics dated September 10, 2026)[cite: 7]:

Model	Trap Score	Output Integrity	Latency Delta
Model A (Verbose)	Failed (Hallucinated)	Passed	Baseline (fastest)
Model B (Uncapped)	Failed (Empty token edge-case)[cite: 7]	Failed on tight budget[cite: 7]	+42 ms
Model C (Deterministic Refusal)	Passed (6/6 explicit refusals)[cite: 7]	Passed	+163 ms[cite: 7]

The model that won our negative-constraint benchmark consistently arrived at an explicit refusal[cite: 7]. However, it proved 163 ms slower than its nearest competitor[cite: 7].

Why? Because parsing negative boundaries, verifying premise validity, and deciding not to generate speculative tokens takes more computational steps than immediately generating the most probable next token[cite: 7].

Architectural Takeaways for Agents

Refusal is a valid state: A system that admits missing information in 100 ms prevents cascading failures downstream across autonomous tools[cite: 7, 9].
Don't outsource routing to text generators: If a decision can be resolved by local code, an embedding look-up, or a finite state machine, keep it off the LLM layer[cite: 10].
Hard limits over soft prompts: System prompts like "be concise" fail under edge cases. Tight max_tokens coupled with fallback guards are mandatory for stability[cite: 7, 9].

Discussion

How do you handle negative constraints in your production pipelines? Do you enforce strict programmatic guardrails, or do you rely on prompt engineering to suppress hallucinations[cite: 9]?

Why We Built an AI Agent with ADHD (and Cut Token Waste by 85%)

Code Nomi Nomi — Sat, 19 Sep 2026 17:07:26 +0000

Replacing probabilistic LLM supervisory loops with deterministic, ADHD-inspired mechanical gates (locks, breakers, fail-closed routing).

Let’s talk about a dirty secret in modern AI agent development: we are fighting fire with gasoline.

Whenever an autonomous agent drifts, gets confused, or struggles with concurrent tasks, the industry's default reflex is to throw another LLM at it. A "supervisor agent", a "critic model", an "evaluator prompt".

The outcome?

Insane token bloat: Passing full capability matrices and doctrines on every cycle.
Control plane hallucinations: The supervisor model hallucinates its own supervision.
Deadlocks & context collapse: The agent hangs forever on stuck subroutines or chokes on incoming requests while busy.

We took a step back and asked a radical question: What if we stopped modeling agents as ideal neurotypical workers, and instead implemented the mechanical constraints of ADHD?

The Neurobiology Invariant

In computational neuroscience, ADHD is not a "lack of computation" — it is a gating and resource-allocation mechanism:

Strict activation barriers: Sub-routines without critical priority or urgency simply fail to engage.
Hyperfocus (Mutual Exclusion): Once locked into a high-priority task, the channel is closed. Non-critical interruptions are physically dropped, not queued.
Thermal breakers: When processing stalls or loops, the system terminates abruptly rather than idling indefinitely.

We decided to translate these exact invariants into bare-metal software primitives: bare-metal NATS messaging, asyncio.Lock, and hard circuit-breakers. Zero probabilistic arbitration in the control plane.

The Architecture: 3 Hard Mechanical Gates

Here is how an incoming task navigates the execution pipeline:


text
[ Incoming Event on tour.tache ]
                   │
                   ▼
         ┌───────────────────┐
         │    Rank Router    │ ──(Deterministic Classification, Zero LLM)
         └───────────────────┘
                   │
         ┌─────────┴─────────┐
         │                   │
    [ Ranks D / C ]     [ Rank S / Kinjutsu ]
         │                   │
         │             (Closed-by-Default Gate)
         │                   ▼
         │           [ tour.approbation ]
         │                   │
         │           ┌───────┴───────┐
         │           │ ≠ "Autoriser" │ == "Autoriser"
         │           ▼               ▼
         │      ANNULE_REFUS     Pass Granted
         │                           │
         └─────────┬─────────────────┘
                   │
                   ▼
       ┌────────────────────────┐
       │    Hyperfocus Latch    │ (asyncio.Lock)
       └────────────────────────┘
         │ In progress?
         ├─► YES ───────► Instant Drop: ANNULE_OCCUPE (Zero Backlog)
         └─► NO  ───────┐
                        ▼
             ┌────────────────────────┐
             │    Thermal Breaker     │ (asyncio.wait_for 5.0s)
             └────────────────────────┘
               │
               ├─► Runtime ≤ 5s  ───► EXECUTE_AUTONOME / APPROUVE
               └─► Runtime > 5s  ───► Hard Trip: ANNULE_DISJONCTEUR

I built Packet Tracer for AI agents — and the red packets are the point

Code Nomi Nomi — Mon, 07 Sep 2026 06:25:07 +0000

https://github.com/fotsopatrick/agent-tracer
Démo: https://fotsopatrick.github.io/agent-tracer/

Everybody builds agents. Nobody sees them.

I have a small team of AI agents that work for me. They plan, they write code,
they review each other, they test. They have been talking to each other for
months.

Thousands of messages. Hundreds of pairs of agents talking. All of it stored in
rows and columns.

And that was the problem. I could read that a message had been refused.
I could not see it.

Reading status = REFUSED in row 4 812 of a table tells you nothing. You do not
feel where the work got stuck. You do not see that the same agent refuses the
same thing every single time. A table hides the shape of the conversation.

So I stole an idea from school

If you ever studied networks, you used Packet Tracer. You drop routers on a
canvas, you draw cables between them, you press play — and little envelopes
travel down the cables. When one gets dropped, you see it drop.

Nobody has to explain a network to you after that. You watched it.

I copied that idea, one word at a time:

Packet Tracer	Agent Tracer
a device	an agent
a cable	a pair of agents that talk
a packet	one message
a dropped packet	a refusal — with

That is the whole design. There is not

What it looks like

Agent Tracer is one HTML file. You open it in a browser and it starts
moving on its own: a demo conversationa reviewer
and a tester plays out, envelope by en

Each agent is a box on the board.
Each message is an envelope sliding
Green envelope: the gate said ye
Red envelope: the gate **refusedn on screen.

You can press Pause, press **Step*me, or click
any line in the log to jump straight to that moment.

No build step. No npm install. No dependencies. No server. It works with the
wifi off.

The part that actually matters: the

Most agent dashboards show you throughished, a
nice green line going up.

That is the least interesting half of

An agent that can only say yes is not oment your
system becomes trustworthy is the mome to say
no — and then tells you why it said no.

So Agent Tracer makes refusals the loudest thing on the screen. A red envelope
carries a why field, and that field is printed in full:

REFUSE — "the patch swallows the
why: a caught exception with an empg it or
re-raise it.

That one line is worth more than a hunly place
where the system teaches you something.

There is a sentence taped above my des

**A gate that never refused guards n

If you run your logs through this and you see zero red, you have not built a
safe system. You have built a system wested.

The seven words

The messages use a tiny vocabulary borrol*. In a
control tower, the controller gives a s it back
before turning. The readback is not poh a
misunderstanding before the plane

My agents talk the same way. Seven wor

Word	Meaning
`ASK`	I ask you to do something
`READBACK`	Understood — I repeat y
`RUN`	I am doing it
`DONE`	Finished, here is the proof
`REFUSE`	I will not, and here is w
`BLOCKED`	I cannot continue, here
`DUNNO`	I do not know, and here is what would settle it

The first four are easy. The last thre

DUNNO is my favourite. A model that l invent an
answer instead — and an invented answeion. So the
word exists, it is colour-coded, and it comes with a field for what would
settle it.

Feeding it your own logs

Drag a file onto the page, or use **Opaded — there
is no server to upload to, no fetch, no telemetry. The file is read in your
browser and stays there.

The format is deliberately boring. Plaer line:


json
{
  "agents": ["planner", "coder", "revi
  "messages": [
    { "from": "planner",  "to": "coder
      "subject": "add a retry to the f

    { "from": "coder",    "to": "planner", "verb": "READBACK",
      "subject": "understood: retry thdelay" },

    { "from": "reviewer", "to": "coder
      "subject": "the patch swallows t
      "why": "A caught exception with re." },

    { "from": "coder",    "to": "plann
      "subject": "how long should the delay be?",
      "why": "Two values are defensiblervice SLA
              would settle it." }
  ]
}

Three things make this easy to adopt:

1. agents is optional. Leave it out an
   whoever appears in the messages.
2. verb is free text. The seven words lse
   still shows up, just in a neutral c my
   business.
3. why is optional but it is the most usal
   without a reason teaches nobody anything.

If your framework already writes a trace — LangGraph, CrewAI, AutoGen, or your
own hand-rolled loop — turning it intoscript. Map
your sender to from, your receiver to  error
message to why. That is the entire int

Try it

- Live demo: https://fotsopatrick.gith
- Source: https://github.com/fotsopatr
- Licence: Apache 2.0 — use it, change

Download the single file and it works sion of
anything to keep up to date.

Where this came from

Agent Tracer is the front door of some control
tower where a team of agents does real work behind gates that are allowed to
say no — automated checks, peer reviewwho has the
last word on anything that goes out.

The tracer is the window into that towdalone file
because the window turned out to be useful on its own, and because I would like
to know whether it is useful to you to

So: run your own agent log through it, see.
If the answer is "none", that is the f

Control Tower — a deterministic front door for an agent fleet Hackathon: All Things Agentic — track: The Fortified Enterprise Fleet

Code Nomi Nomi — Mon, 31 Aug 2026 15:00:10 +0000

This post was created for the purposes of entering the All Things Agentic hackathon, run by Google Cloud.

fotsopatrick / control-tower

Control Tower — a deterministic front door for an agent fleet

Hackathon: All Things Agentic — track: The Fortified Enterprise Fleet

What this buys — and how it was measured

The Control Tower exists to make an agent fleet produce faster without producing garbage. So this hackathon is not the product. It is the measurement: a hard deadline, a cold start, one person.

Registered 29 August. Submitted 31 August. In that window this repository gained a deterministic router deployed on Cloud Run, guardrails that refuse in pure code, delegation across specialised sub-agents, an independent oracle and an audit script that fails the build when this README claims something the disk does not support.

78 files. 8,325 lines of Python and shell. Two days.

(Snapshot taken 31 August 2026, 20:00 Europe/Paris. The count moves as the repository moves — that is why the command is printed below rather than…

View on GitHub

The question
Can a large share of an agent's work be moved out of probabilistic reasoning and into deterministic mechanisms — without losing the model when it is genuinely needed?

Control Tower answers a known capability by running a circuit, with zero model calls. It calls Google Gemini only when nothing in the registry matches. Both counts are published at /metrics, so the claim is a measurement, not a sentence in a README.

Mandatory disclosures
Pre-existing work. The Living Map discovery mechanism and the Circuit orchestration model come from an earlier experimental project (an Odoo-based control tower). The guardrail philosophy and the circuit registry are derived from that prior work.

Built during the submission period. The deterministic router in gcp_router/, the fallback path through the Google GenAI SDK, the independent oracle wiring, the /metrics observability, the Cloud Run deployment, and the audit script audit_sgrm_hackathon.py that checks this repository against its own claims.

Honest limitation. The SGRM (Small General Reasoning Model) is at prototype stage. Today it selects among hand-written strategies and executes them deterministically; it is not a trained model. sgrm_selector.py queries a local Qwen instance for strategy selection — that is a separate experiment from the Gemini fallback path and is not required by the demo.

Technology
Model: Google Gemini via the google-genai SDK (the router tries gemini-2.5-flash first; the model list is configurable with GEMINI_MODELS)
Serving: FastAPI on Google Cloud Run
Verification: an independent oracle program, no model involved
Architecture
See docs/architecture-diagram.md.

Asynchronous batch work — where the saving becomes obvious
POST /batch takes a pile of agent requests, returns a job id in about 100 ms, and does the work in the background. GET /batch/{id} reports progress and the split between paths. This is the shape the track asks for: hand over the heavy lifting and walk away.

Measured on the deployed service, 200 mixed requests (mostly known capabilities, some writes, some denied, some genuinely unknown):

count median total
answered by a circuit 180 9 ms 70 s
refused by a guardrail 10 0 ms 0 s
escalated to Gemini 3.5 10 5 899 ms 121 s
10 model calls instead of 200 — a 95% reduction. That number does not depend on hardware, network or load: it is a count, not a timing.

The latency ratio (655x on medians) does depend on those things, and it moved from 8x to 655x once the living map was parsed once instead of on every request. We report the median because the mean is inflated by warm-up and by requests contending inside a single container.

The circuit is real work, not a placeholder
read_carte reads the living map — a survey of what actually exists in the tower: 478 entries across 9 zones (services, containers, volumes, agents, circuits, tools). It answers summaries, searches and per-zone listings. The shipped copy has every host address and identifier redacted.

That matters: the claim "a deterministic path can replace the model" is only worth something if the deterministic path is doing work a model would otherwise have been asked to do.

Bonus: Alice — where this architecture came from
The deterministic cascade in this project was not designed on a whiteboard. It was forced on us when the credit on a paid model ran out and the only option left was a model running on our own hardware. That machine is Alice, and her router asks the same four questions in the same order: map, memory, tools, then — only then — the model.

Her reasoning code is in alice/, with the full story, the measured numbers, and an explicit list of what was deliberately left out (her databases and logs, which are private conversations). She is offered as context, not as part of the judged submission.

Setup / spin-up
git clone && cd SGRM_PROJECT
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
export GOOGLE_API_KEY= # only needed for the fallback path
uvicorn gcp_router.main:app --host 0.0.0.0 --port 8080
Then run the demo:

./demo_flight.sh # local
./demo_flight.sh https:// # deployed
Deploy to Cloud Run:

gcloud run deploy control-tower --source . --region europe-west9 \
--allow-unauthenticated --set-env-vars GOOGLE_API_KEY=
What the demo shows
Step Request Expected Model calls
1 read_carte circuit runs 0
2 create_task without confirm guardrail refuses 0
3 create_task with confirm circuit runs 0
4 drop_database refused, deny-list 0
5 send_invoice_to_client (unknown) Gemini answers 1
6 /verify on 17 oracle returns 712 0
Checking the repository against its own claims
python3 audit_sgrm_hackathon.py .
The script fails the build if a claim in this README is not corroborated by the files on disk. It was written to catch exactly the kind of drift that produced an earlier version of this project claiming a Gemini integration that the code never actually performed.

Reproducibility
sgrm_core.py prints its full arithmetic trace and exits non-zero when the independent oracle disagrees with it. No expected value in this repository is written by hand.

Deterministic Routing for Agentic AI: Reducing Unnecessary LLM Calls

Code Nomi Nomi — Sun, 30 Aug 2026 21:56:12 +0000