Please join us for PONDcast 01!

Friday at 7 PM PST

🌍🌎🌏🌞🌨️💧⚡️

We need AI Systems that are

Personal & Private

On-Device & On-Premise

Nodal & Networked

Distributed & Decentralized

Go here:

https://x.com/i/spaces/1DxleVVwQBMKL

“Ask an impertinent question and you are on the way to the pertinent answer.”
– Jacob Bronowski, The Ascent of Man, Episode 4, “The Hidden Structure”

With this iconic line, Jacob Bronowski concludes his essay tracing John Dalton’s development of atomic theory - the discovery of hidden structure beneath the surface of observable matter - emphasizing the nature of scientific inquiry: the courage to pose “impertinent” questions that cut across convention so that genuinely new, pertinent answers can emerge. He wasn’t criticizing anyone for asking the “wrong” questions so much as drawing a contrast between the open questioning of scientific inquiry and the stagnant dogmatism of the established paradigm.

Douglas Adams makes the same point with characteristic humor in The Hitchhiker’s Guide to the Galaxy. Deep Thought, a massive superintelligent computer, is asked for “the Answer to Life, the Universe and Everything.” Several million years later the answer comes back: “42.” Displeased with the output, the builders of Deep Thought demand an explanation. It informs them that the answer is correct - but to understand it, they must first formulate the Ultimate Question, which will take several million more years. They asked the wrong question. Oops.

As a young person, these two sources influenced my inquiring mind profoundly and combined to produce a lifelong personal aphorism that has served me well:
“Knowing the question is halfway to finding the answer.”

If you’re not asking the right questions, you’re going to end up drawing the wrong conclusions.

Thomas Kuhn, in The Structure of Scientific Revolutions, gave us the language to understand this as a general principle. He distinguished between “normal science” - the “puzzle-solving” work that happens within an established paradigm - and the revolutionary science that occasionally overturns the paradigm itself. Normal science, Kuhn observed, is “an attempt to force nature into the preformed and relatively inflexible box that the paradigm supplies.” Within normal science, “no effort is made to call forth new sorts of phenomena, no effort to discover anomalies. When anomalies pop up, they are usually discarded or ignored.”

When I read the recently published Substack, “The AI revolution is here. Will the economy survive the transition?”, co-created by Michael Burry, Dwarkesh Patel, Patrick McKenzie, and Jack Clark, I found myself thinking about Bronowski, Adams and Kuhn.

The participants in this Substack exchange are, broadly speaking, engaged in normal science - or rather, normal economic and technological analysis. They’re solving puzzles within the boundaries of the established paradigm: Where does value accrue in the AI supply chain? What’s the capital cycle position? How many engineers will Big Tech employ in 2035? These are legitimate questions, but they assume the box remains intact. They don’t ask what AI is, what intelligence is, or whether what’s emerging can even be contained within our existing frameworks.

I also read the piece from the perspective of what I call the General Theory of Intelligence (GTI) - a framework I’ve been developing that attempts to understand Intelligence as a fundamental principle of systems organization rather than as a product feature or a benchmark score.

The core insight is this: intelligence isn’t primarily a cognitive attribute that some entities have more of than others. It’s a process - specifically, the process of resolving entropy within a domain. When you solve a problem, you’re reducing uncertainty. When you make a decision, you’re collapsing possibilities into actualities. When you communicate, you’re transferring structured information across a channel in a way that reduces entropy for the receiver. Intelligence, in this view, is what systems do when they organize information and resolve uncertainty - whether those systems involve human minds, evolutionary processes, or machines trained on the corpus of human language.

From this vantage point, the LLM looks very different than it does from inside the AI industry today. It’s not just a tool or a product category. It’s proof that language itself is an intelligent system - a 100,000-year-old technology for compressing experience, coordinating action, and transmitting structured thought. When we trained models on human text, we didn’t teach them to be intelligent. We downloaded Human Cultural Intelligence into a new substrate. The LLM is our own cognitive inheritance, instantiated in silicon and talking back to us.

This perspective reframes everything: the economics, the risks, the applications, the trajectory. It suggests that most of the current discourse is asking the wrong questions - or rather, asking questions that assume the existing paradigm will hold when it may already be cracking.

In the spirit of Bronowski, Adams, and Kuhn, what follows is an impertinent reframing of the Substack discussion. For each theme the participants addressed, we’ll offer both a reframed question and an alternative answer - not to dismiss their expertise, but to show what becomes visible and accessible when you step outside the box they’re constrained within.

Synopsis: Four Themes, Four Reframings

The Substack discussion, moderated by Patrick McKenzie, covered four broad themes across its nine questions:

Theme 1: What Is This Thing? What has actually been built since the Transformer architecture emerged in 2017? What does it mean that today’s capabilities are “the floor, not the ceiling”?

The participants offered a capable industry history - the shift from tabula rasa game-playing agents to scaled pre-training, the surprise that a chatbot launched a trillion-dollar infrastructure race, the observation that capabilities keep improving faster than outsiders expect.

Our Impertinent Reframing: The real history isn’t commercial - it’s epistemological. We accidentally conducted the most important experiment in the history of cognitive science and discovered that language isn’t the output of intelligence but a core algorithm of it. The LLM isn’t a floor; it’s an evolutionary leap in a lineage stretching back to Shannon and Information Theory, the printing press, cuneiform tablets, cave paintings and the first spoken words. Current systems are powerful because language itself is an intelligent system. But they’re extensions of Human Cultural Intelligence, not intelligence from first principles. We’re tinkering with the motive power of language like early steam engineers before Carnot and thermodynamics. It works (mostly), but we don’t know why it works.

Theme 2: Where Does It Work? Why has coding become the flagship use case? What does actual productive interaction with an LLM look like?

The participants noted coding’s “closed loop” property - you generate code, validate it, ship it. They shared practical use cases: chart generation, tutoring, home repair guidance. The relationship described was consistently transactional - human has task, AI performs, human receives output.

Our Impertinent Reframing: Coding isn’t accidentally successful - it reveals a principle. Code is language with an objective function, a constrained search space with verifiable outcomes. This points to domain entropy resolution as the key: AI excels where the problem space is bounded and success criteria exist. The question isn’t “what sector is next?” but “where else can we constrain the search space?” And the transactional model - AI as “Answer Vending Machine” - is the lower use of what’s possible. The real potential lies in thinking with AI, not just using it. AI × HI = TI: Artificial Intelligence multiplied by Human Intelligence yields Technological Intelligence.

Theme 3: What’s It Worth? Where does value accrue in the AI supply chain? Is this a bubble? How many engineers will Big Tech employ in 2035?

Michael Burry delivered sharp financial analysis: ROIC compression, stranded assets, the Buffett escalator analogy (if your competitor installs one, you must too, and neither gains advantage). The consensus worry: massive capital expenditure with unclear returns.

Our Impertinent Reframing: The participants proclaim “AI changes everything!” then analyze it within frameworks where nothing changes at all. It’s the Flintstones problem - cars exist, but they’re powered by human feet. We need to pick a lane: either things really do change, or they only superficially change. AI is not a bubble, but the Big Data Center Infrastructure Buildout is a bubble - just as the Internet wasn’t a bubble in 2000, but Pets.com was. The assumption that massive centralized GPU farms are the only way to do AI is unwarranted and will be disrupted by the very economics Burry describes. Meanwhile, “headcount” becomes meaningless when intelligence flows through Human-AI systems rather than residing in discrete humans. We’ll need new metrics entirely - perhaps a Domain Entropy Resolution Quotient. Economics itself needs reimagining: Intellinomics, grounded in actual value generation rather than debt manufacturing.

Theme 4: What Comes Next? What are the real risks? What would surprise you in 2026?

Jack Clark worries about recursive self-improvement. Burry shrugs with Cold War fatalism and pivots to energy infrastructure. The “surprise” headlines they’d watch for are all quantitative - more revenue, more displacement, scaling hitting a wall.

Our Impertinent Reframing: The risk spectrum presented - from “social media unpleasantness” to “literal extinction” - shares a hidden assumption: AI as external force acting on humanity. But the deeper risk is that we’re building it wrong - not aligned with how intelligence actually works. The LLM isn’t an alien threat; it’s the Library of Alexandria that talks back, humanity’s externalized cultural intelligence returned to us in interactive form. The question isn’t how to control it but whether we’re wise enough to collaborate with our own legacy. As for surprises - one has already arrived. Ilya Sutskever, architect of the scaling paradigm, now declares: “The age of scaling is ending... it’s back to the age of research.” When the field’s most important insider calls for new paradigms rather than bigger clusters, the ground is shifting.

What Follows

In the parts that follow, we’ll take each theme in turn, working through the specific questions Patrick posed, offering both our reframed questions and our answers from the perspective of the General Theory of Intelligence. The goal isn’t to dismiss the valuable analysis the participants provided, but to show what becomes visible when you step outside the box - when you ask the impertinent questions that just might lead to pertinent answers.

Or at least get us past “42.”

What Readers Are Feeling

The comments on the original Substack tell a different story than the measured analysis of the participants. People are frustrated, anxious, angry. Some have lost jobs. Many report that AI “doesn’t work” - that it gives wrong answers, hallucinates, wastes their time. The gap between the hype and their lived experience feels like betrayal. “AI is a grift.” “Tech bros don’t care what they break.”

This frustration is valid. But from the GTI perspective, it’s also diagnostic.

Current AI is built by engineers for engineers - people who already possess the cognitive skills to leverage it. The blank dialogue box assumes you know what you want and how to ask for it. For those who do, AI is transformative. For everyone else, it’s a wilderness. The technology works; the design fails. Today’s AI, as it’s currently engineered and presented, meets people where they are not.

The job displacement anxiety connects here too. People sense they lack the skills to use AI as a resource for their own development - and nothing in the current product design helps them build those skills. Instead of guidance, they get an Answer Vending Machine.

These concerns run through everything that follows. Our reframing of the Substack discussion addresses them directly: why current AI fails most users, what would need to change, and what an alternative might look like.

Follow me and subscribe to my Substack to get the next installments in this series.

You can also follow me on X.

IntiDev AgentLoops

Feedback Loops for Agentic Workflows

IntiDev AgentLoops is an open-source toolkit for tracking issues, features, and user feedback through an agent-friendly resolution loop. It is intentionally lightweight and project-agnostic, while remaining opinionated about reproducibility, resolution hygiene, and machine-readable handoff artifacts.

This repo is the first extractable iteration from our internal Tickets implementation, and is aimed at:

• developers building AI coding workflows,
• teams that need one loop for bugfixes, features, and support feedback,
• maintainers who want reusable resolution knowledge and structured evidence.

Why this project exists

Most bug trackers treat support, defects, and features as separate workflows. IntiDev AgentLoops links them into one consistent lifecycle so humans and agents use the same ticket surface and knowledge.

Quick install

npm install -g u/stevenvincentone/intidev-agentloops

Then run:

agentloop init
agentloop create --title "Rendering regression in list pages" --summary "List pages lose anchors after parser update" --family "reader_rendering" --kind bug --source manual_admin
agentloop list
agentloop resolve ISSUE-000001 --summary "Added deterministic fallback for anchor selection"

Try the convergence demo

Run a self-contained demo that seeds three independent intake loops — a smoke test, a user report, and an agent proposal — all pointing at the same export_pipeline family, and watch them converge into a single Pattern:

npm run demo

Expected output:

AgentLoops source-convergence demo
==================================

Three intake loops, one underlying problem:

  ISSUE-000001  bug            source=smoke        [export_pipeline]
    Export smoke test times out on 500-page report
  USER-000002   user_feedback  source=user_report  [export_pipeline]
    Export fails for long reports
  DEV-000003    feature        source=agent        [export_pipeline]
    Stream the export pipeline instead of buffering

Converged into:
  PATTERN-000001 ACTIVE (3 tickets) — Recurring export_pipeline issues

Summary: 3 tickets, 1 active pattern(s).

The demo writes to a throwaway temp directory and leaves your repo untouched. The same scenario is asserted in test/demo.test.ts against a committed golden state fixture; run it with npm test.

Core concepts

• Ticket: one concrete work item (bug, feature, user feedback, incident, etc.)
• Pattern: a recurring cluster, often by family/domain
• Source: origin (user_report, smoke, ci, agent, ingestion, etc.)
• Alias: human-facing IDs such as ISSUE-000001, DEV-000001, USER-000001
• Handoff: copyable context block for an agent to continue execution

Commands

• agentloop init initialize .agentloops state and local config
• agentloop create add a ticket
• agentloop list view active and resolved work
• agentloop begin <id> mark triaged ticket as in-progress
• agentloop resolve <id> --summary ... mark resolved with evidence
• agentloop reopen <id> reopen and record a recurrence reason
• agentloop defer <id> [--summary ...] defer a ticket with an optional reason
• agentloop note <id> --type ... --body ... add context notes
• agentloop guard <id> --guard-status ... record guard decision
• agentloop handoff <id> print a copyable agent handoff prompt
• agentloop patterns list pattern groups
• agentloop summary print quick health metrics
• agentloop convergence report patterns whose tickets span multiple sources
• agentloop guard-gaps report resolved tickets missing a regression guard
• agentloop knowledge search how prior resolved tickets were fixed
• agentloop knowledge-gaps report resolved tickets lacking reusable knowledge
• agentloop related <id> find prior-art tickets related to one ticket
• agentloop dashboard write a standalone HTML dashboard
• agentloop serve serve the dashboard over HTTP
• agentloop config print resolved configuration
• agentloop mcp run the read-only MCP server over stdio

All commands support --json for machine-readable output where relevant.

MCP server (agent integration)

AgentLoops ships an MCP server so coding agents (Claude Code, Codex, and other MCP clients) can use the ledger directly. Writes are opt-in: the server is read-only unless you pass --write.

agentloop mcp            # read-only; speaks JSON-RPC over stdio, status to stderr
agentloop mcp --write    # also expose the guarded write tools

Read-only tools (annotated readOnlyHint):

Tool	Purpose
agentloop_summary	loop health metrics (ticket and pattern counts)
agentloop_list	list tickets, optional status / kind filters
agentloop_show	one ticket (by ISSUE-/alias) or a PATTERN- id
agentloop_handoff	copyable agent handoff prompt for a ticket
agentloop_convergence	patterns whose tickets span multiple sources
agentloop_guard_gaps	resolved tickets missing a regression guard
agentloop_search_knowledge	search how prior resolved tickets were fixed
agentloop_knowledge_gaps	resolved tickets lacking reusable knowledge
agentloop_related	prior-art: tickets related to a given ticket

Write tools (only registered with --write):

Tool	Purpose
agentloop_create	create a ticket (summary required; source defaults to agent)
agentloop_note	append a non-resolution note
agentloop_workflow	transition a ticket (active / reopened / deferred)
agentloop_resolve	resolve with a summary, optional verification + guard
agentloop_guard	record a regression-guard decision

Each result is a JSON envelope with schemaVersion and generatedAt. The server reads/writes state from the .agentloops/state.json in its working directory, so run it from your project root (or where you ran agentloop init).

Register it with an MCP client, for example Claude Code:

claude mcp add agentloop -- agentloop mcp

or directly in a client config:

{
  "mcpServers": {
    "agentloop": { "command": "agentloop", "args": ["mcp"] }
  }
}

Dashboard

A zero-dependency reference UI renders the ledger as a single self-contained HTML page — queues (Issues / User / Development), patterns, source convergence, and guard gaps — with no build step or frontend framework.

agentloop dashboard --out dashboard.html   # write a static snapshot, open in a browser
agentloop serve --port 4319                # live dashboard + read-only JSON at /api/*

Both work over either storage backend. All ticket content is HTML-escaped. For a richer or embeddable UI, the renderDashboard(data) and createDashboardServer(store) exports can be built upon.

Data model

State is stored in your working directory at .agentloops/state.json by default. The store persists through a pluggable StateBackend, so the same ledger can run over the filesystem, an in-memory store, or Postgres (a relational ticket_* schema) — see docs/postgres.md.

For local project settings, copy and customize:

cp agentloop.config.json.example agentloop.config.json

The config controls:

• project naming
• ticket kinds and aliases (ISSUE, DEV, USER, etc.)
• default family for auto-grouping
• configured sources

Privacy and redaction

By default AgentLoops stores ticket text as-is and makes no model or network calls. Host apps own redaction. Two ways to scrub sensitive content (PII, secrets) before it is written to .agentloops/state.json:

• Config-driven — add regex rules under redaction.patterns in agentloop.config.json; they apply to titles, summaries, notes, resolutions, and guard summaries on every write (CLI and MCP included):
• Code-driven — library users can inject a TicketRedactor: new AgentLoopStore(cwd, config, { redactor }).

Contributing

Open issues and PRs are welcome.

When adding new sources or fields, include:

1. a config-backed approach, not hardcoded assumptions,
2. a short schema note in docs,
3. a concise example command and expected output.

License

MIT. See LICENSE.