Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save cfulger/19779c3cab04d2c8b47b496168386d1e to your computer and use it in GitHub Desktop.

Select an option

Save cfulger/19779c3cab04d2c8b47b496168386d1e to your computer and use it in GitHub Desktop.

The AI that learned when to fire itself

A Framework for AI-to-Deterministic Transitions


I was deeply enthusiastic about the concept of an AI controlling a computer locally — a personal AI assistant with its own private computer. But AI would fail on simple tasks, and even worse, it would fail on tasks it had already performed correctly. That second failure mode is the most frustrating: being unable to repeat something that was once executed perfectly.

So — you have an AI that performs recurring tasks. Every time it runs, it costs money, takes time, and risks hallucination. Many of these tasks are mechanical; the AI does the same thing every time. The goal is for the AI to identify which tasks are mechanical, write scripts to replace itself for those tasks, and remain available only for the work that genuinely requires intelligence.

AI should discover what needs intelligence and what doesn't, offload the mechanical work, and allow the system to call it back only when the world changes enough to require a new decision. It should liberate the CEO from the drudgery of spreadsheets.


The Inversion

Intelligence is the initiator; the deterministic system is the loop. The system acts on what has been proven to work and calls the AI only when it encounters something that genuinely requires understanding. The AI is downstream. The machine takes the wheel once a process is automated.

Three consequences flow from this:

  • The Mechanism: The AI identifies what needs intelligence, offloads the rest, and intervenes only when conditions change.
  • The Trust: Higher, because it is earned and verified mechanically but revoked instantly.
  • The Cost: Drops significantly because the AI only appears when it truly matters.

Many recurring tasks are structured work pretending to be MEANING work. The first time you say, "check disk usage and alert me if it's over 80%," you need intelligence. Something has to understand your intent, determine which command to run, decide which threshold matters, and compose a message if something is wrong.

After that first time? It's the same bash command, the same comparison, and the same alert logic. Forever. Intelligence was needed once; the execution is mechanical thereafter. You no longer have to doubt it.


Core Mechanism

Phase 1 — The AI Designs Its Own Replacement

When a new recurring task arrives, the AI runs it normally. But it also receives a second instruction: "Design a trigger script that can handle this task without you."

The AI analyzes the task and writes a bash script that captures the mechanical logic. For a disk check, the AI produces exactly what you'd expect. The AI correctly identifies the boundary: I'm not needed here. A script can do this.

Phase 2 — The Machine Audits the Brain

Both paths run simultaneously on every tick. The bash script executes in milliseconds; an AI container runs the same task in 30–75 seconds. A parallel validator compares their outputs and method and presents it to a human after successful N runs with identical outputs.

If they disagree, the counter resets. The AI's output is always used during validation — the safer path while trust is being established. This isn't A/B testing; it's a rigorous audit where the AI serves as its own benchmark until the machine proves it can replicate the intelligence with zero-cost determinism.

Human at the gate → User approves method/output once after it passes validation, and then it runs on its own until something breaks.

Phase 3 — The Machine Runs Alone

Once promoted, the script runs by itself. No Docker container. No AI, no API cost.

  • Exit 0: Nothing to report. Done.
  • Exit 1: The trigger fired (e.g., the disk is full). Now the AI is called — not to check the disk again, but to compose the alert message. The script already knows what happened; the AI handles how to communicate it.
  • Exit 2: The script errored. After one failure, it is demoted back to parallel validation. Trust is revoked. The machine must earn it back.

This is a mechanism for the system to govern its own autonomy transitions based on measured evidence. The AI becomes the CEO — called in for judgment, not data processing.


The Sentinel Paradox

This much seems straightforward. The complications begin when you ask: What happens after promotion?

Once a script is promoted to TRUSTED, it runs alone. The AI is gone. Who watches the script? You need a sentinel — something that detects when the script encounters an input it wasn't proven on. The natural instinct is to make this sentinel "smart": let it learn patterns, adapt to new data, and flag anything that "looks wrong."

But here's the problem: a smart sentinel is flexible. A flexible sentinel can have bugs and miss anomalies it wasn't specifically tested on. The moment it does, you've introduced a new problem alongside AI hallucinations — one that is invisible and running on every tick with full authority.

The sentinel must be rigid. It can only check against the specific structural features present during PARALLEL validation — the exact columns, types, formats, and shapes of the inputs the human saw and approved. If the current input matches those features, the sentinel passes it through. If any structural dimension differs, it flags it. That's all.

This feels limiting. It means the sentinel cannot catch semantically novel inputs that happen to look structurally identical to proven ones. But that rigidity is the feature. The sentinel's authority traces entirely back to what the human approved. It doesn't guess or infer; it compares against a fixed reference. The things it catches are certain; the things it misses are acknowledged as the system's honest boundary — the Gödel boundary.

The rigidity of the sentinel is not a design choice; it is a consequence of wanting certainty. Any flexibility would require the sentinel to act on a spectrum of untested inputs. To ground the chain, the sentinel must remain fully mechanical, tracing its authority to a single external validation event.


The Single Touch

That external validation event is the human. At the PARALLEL → TRUSTED gate, a human reviews the outputs/method and confirms they are correct. We call this constraint the Single Touch.

Every guarantee in the system traces back to this moment:

  • The sentinel's baselines come from the inputs the human approved.
  • Baseline expansion requires PARALLEL agreement (the same mechanism).
  • Demotion is triggered by the sentinel (which traces back to the human).
  • Self-healing generates a new script, which must pass PARALLEL again (the same standard).
Human approves outputs
    → Sentinel baselines are set
    → Script is promoted
    → Future inputs are compared to these baselines
    → Any expansion requires the same standard of evidence

The Single Touch is not minimalism for its own sake. It is the realization that you only need one external grounding event if every downstream decision traces back to it mechanically.

The human's judgment is the axiom; everything else is a deduction from that axiom by the machine. It accounts for Gödel's second incompleteness theorem, which suggests a sufficiently powerful system cannot prove its own consistency from within itself.


What happens when the script fails?

Sometimes the AI writes a script that doesn't work. PARALLEL disagrees. The AI tries again with the error details. If it fails K times, the circuit breaker fires and the system enters MEANING — where the AI handles the task every tick without a script.

But MEANING cannot be a dead end. If it were, every task that fails mechanization once would be condemned to run on expensive and uncertain AI forever. The system needs a way back.


The Mechanism of Narration

The AI processes the task however it sees fit — unconstrained, flexible, and fresh. But after each run, the machine asks one additional question: "Describe what you just did as a structured sequence of steps." The machine logs that description faithfully. It doesn't understand the steps, and it isn't asked to do anything with them — for now. It just files the notes.

The AI is the CEO making decisions; the machine is the secretary taking minutes. The secretary doesn't tell the CEO how to think; the secretary just records what happened.

MEANING state:

  1. AI processes task freely → produces output.
  2. Machine asks: "Describe what you did."
  3. AI narrates: "Step 1: extracted date. Step 2: counted rows. Step 3: wrote summary."
  4. Machine logs the description (building a structured history across runs).

Over time, these narrations either stabilize or they don't. If the AI describes the same structure N times in a row, the machine has empirical evidence of convergence without ever having imposed a method. The scaffold isn't dictated; it emerges from the AI's own repeated descriptions.

This is cleaner than injecting instructions. If the task changes, the AI naturally adapts its approach and describes the new process. No stale scaffold fights the new reality. The machine sees the description shift, resetting the convergence signal.


Re-evaluation and Hybridization

After N runs, the AI is called back to answer a different question: "Look at your own narrated history for each step. Has your method stabilized? And for the steps where it has — could a script replicate what you're doing?"

This is the AI re-evaluating its own work. It looks at N logged narrations and may say: "I extract the date the same way every time. A script could do this." Or it may look at another step and say: "I write a different summary every time based on meaning. No script can do this."

The machine doesn't make this judgment; the AI does. But the machine controls what happens next: if the AI says a step is mechanizable, the machine triggers the constructive proof — generate a script, run it in PARALLEL, and compare. If the proof succeeds, the step moves from AI to script.

Every N runs in MEANING or HYBRID:

  • AI reviews its own narrated history.
  • Decision A: "Step 1 has converged; a script could do this." → Machine generates script → PARALLEL test → If passes: Step moves to SCRIPT.
  • Decision B: "Step 2 varies every time; not ready." → Stays with AI; keep logging.
  • Decision C: "Step 3 is stable but requires understanding." → Stays with AI (converged but not mechanizable).

This is how HYBRID emerges naturally. The AI identifies which of its own steps can be scripted. The task splits — the script handles the proven side, and the AI handles the unproven side. The cycle continues: every N runs, the AI re-evaluates the steps that remain with it. Most tasks AI is doing are hybrid. Data gathered shows that — not only meaning, nor only mechanic steps.


The Crucial Asymmetry

The AI can prove a step IS mechanizable (constructive proof). But it can never prove a step ISN'T mechanizable. Maybe the script was poor, the prompt was flawed, or a future model will handle it. The door never closes.

When the circuit breaker fires, it is not claiming a task requires intelligence forever. It is an empirical surrender: "I have failed enough times to stop trying for now." This is why MEANING is always provisional. The observatory keeps logging, and the system re-checks convergence with fresh data. The door never closes permanently on what the system cannot prove is permanently closed. The circuit breaker is not a classification — it is a disciplined pause.

The narrated history makes this possible. It provides the AI a structured record of its own behavior — not because it was told to follow a structure, but because it described what it naturally did. Patterns are discovered, not prescribed.


Conclusion

The basic mechanism: AI generates its replacement (or hits the circuit breaker), the machine proves it, trust is earned through agreement, and demotion is instant on failure. For simple recurring tasks, this saves real money and delivers real trust.

Flexible understanding, mechanical execution. This principle survives any technological shift. It doesn't matter whether the deterministic layer is Python or bash, or if the intelligence layer is Claude or Gemini. The boundary between understanding and execution is the critical architectural decision.

Too much AI autonomy leads to hallucinated side effects and costs that scale with volume. Too little, and you lose the ability to handle ambiguity. This project provides one answer: let the AI draw its own boundary, then verify it mechanically. The boundary is not fixed; intelligence should discover when it moves. Promotion is earned; demotion is swift.

One of AI's best features is knowing when it's not needed. One of a machine's best features is proving it. We might find the territory that genuinely needs a dreamer is smaller than we thought.

The CEO shouldn't be doing spreadsheets.


Open question: How to remove the human at the gate? Prescribe what correct looks like and let everything trace back to that axiom-like statement?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment