The "consumption" frame is more honest than "craft," agreed. But it falls into the exact same hole. Taste accumulation, attention capture, gift economy, signal fortress—they're all variations of "how do I assetize the byproducts?" The frame changed, but the question didn't: what do I get out of this?
The author already touched on a better answer. Scenius worked because of the "permission to fuck around." Nobody expected your Arduino to ship. But the conclusion hands you four value-capture strategies and quietly revokes that permission. "Play freely, but collect the exhaust" isn't permission—it's a conditional license.
I once learned songwriting from an indie musician who refused autotune and wrote by hand. He said the point of busking isn't playing because there's an audience. It's playing when nobody stops. You play anyway. That's how you find your sound.
This gets at the root of "evaluative anesthesia." It's not that our tools are too powerful. It's that we're asking "is this valuable?" at every step. A busker doesn't ask that. Taste and judgment accumulate as a residue of immersion, not deliberate capture.
What vibe coding needs isn't a smarter consumption strategy. It might just be the courage to play to an empty street.
I'm looking at this from a slightly different level of abstraction.
The CLI approach definitely has practical benefits for token reduction. Not stuffing the entire schema into the runtime context is a clear win. But my main interest lies less in "token cost" and more in "how we structure the semantic space."
MCP is fundamentally a tool-level protocol. Existing paradigms like Skills already mitigate context bloat and selection overhead pretty well via tool discovery and progressive disclosure. So framing this purely as "MCP vs CLI" feels more like shifting the execution surface rather than a fundamental architectural shift.
The direction I'm exploring is a bit different. Instead of treating tools as the primary unit, what if we normalize the semantic primitives above them (e.g., "search," "read," "create")? Services would then just provide a projection of those semantics. This lets you compress the semantic space itself, expose it lazily, and only pull in the concrete tool/CLI/MCP adapters right at execution time.
You can arguably approximate this with Skills, but the current mental model is still heavily anchored to "tool descriptions"—it doesn't treat normalized semantics as first-class citizens. So while the CLI approach is an interesting optimization, I'm still on the fence about whether it's a real structural paradigm shift beyond just saving tokens.
Ultimately, shouldn't the core question be less about "how do we expose fewer tools," and more about "how do we layer and compress the semantic space the agent has to navigate?"
shell is already an answer to your questions. Basic shell constructs and well-known commands provide the abstractions you ask about. `cat`, `grep` and pipes and redirects may not be semantically pure, but they're pretty close to universal, are widely used both as tools and as "semantic primitives", and most importantly, LLMs already know how to use them as both.
Haha I agree that my opinion is kind of that
But more like ports & adapters for semantic space, not just IO boundaries.
If we can abstract the tools one layer further for ai, it might reduce the attention it needs to spend navigating them and leave more context window for actual reasoning
I broadly agree with the caution against naive "conscious AI" narratives, but I think this essay underestimates a key idea from Hofstadter’s GEB.
Hofstadter's claim was not that consciousness is "just computation" in a trivial sense, but that within the space of computable processes, certain self-referential, symbol-manipulating systems can give rise to something structurally indistinguishable from consciousness — a "strange loop."
In that framing, consciousness is not a magical biological add-on, nor merely subjective illusion, but an emergent property of sufficiently rich, recursive models that represent themselves and the world simultaneously.
Biology may be one implementation of such loops, but it’s not obvious that it's the only possible one. Dismissing computation wholesale risks conflating "today's AI architectures" with "the entire space of computable systems."
The real open question, I think, isn't whether computation can support consciousness-like phenomena, but what class of computations is required — and whether our current systems even approximate it.
Hi HN,
I've been building autonomous agents and noticed a recurring failure mode: as business logic becomes more complex, even the most capable LLMs struggle to maintain consistency. I realized the problem isn't just the "brain" (the agent), but the lack of a structured "world" for it to inhabit.
Most current frameworks are Agent-Centric, forcing the agent to manage its own state, memory, and environmental rules all at once. This post explores a shift toward World-Centric Orchestration, where we prioritize the environment's state and rules first.
In this piece, I discuss:
- The Decoupling of Agency and Environment: Why the agent should be an "actor" within a world that enforces its own constraints.
- State-Driven Reliability: Using state machines to define valid action spaces, reducing the hallucination surface.
- Pheromone-Inspired Memory: A rough approach to managing long-term context using weighted relationship graphs and lexical indexing.
The "Mind Protocol" is my attempt to formalize this architecture. I'm curious to hear from others who are moving away from simple "loop-and-prompt" patterns—how are you handling state consistency and world-building for your agents?
I'd love to hear your critiques and thoughts on this approach.
I see Engram less as a memory efficiency trick and more as an architectural attempt to address *context drift*, which feels like a fundamental issue in current LLMs.
As context grows, models are forced to continuously re-derive what should be stable state (entities, facts, local invariants) from attention alone. Over long horizons, this implicit reconstruction inevitably drifts. From that angle, Engram’s value isn’t just O(1) lookup
it’s that state is externalized, managed outside the core reasoning path, and injected only when relevant.
That separation feels important. Instead of hoping attention can both reason and maintain coherence indefinitely, the model gets a way to re-anchor itself to stable references. In that sense, this looks less like “better recall” and more like a step toward explicit state management for LLMs.
I suspect architectures that treat memory as an external, selectively injected primitive will matter more for long-running agents than further scaling context windows.
I've been building autonomous agents and noticed a recurring failure mode: as business logic becomes more complex, even the most capable LLMs struggle to maintain consistency. I realized the problem isn't just the "brain" (the agent), but the lack of a structured "world" for it to inhabit.
Most current frameworks are Agent-Centric, forcing the agent to manage its own state, memory, and environmental rules all at once. This post explores a shift toward World-Centric Orchestration, where we prioritize the environment's state and rules first.
In this piece, I discuss:
- The Decoupling of Agency and Environment: Why the agent should be an "actor" within a world that enforces its own constraints.
- State-Driven Reliability: Using state machines to define valid action spaces, reducing the hallucination surface.
- Pheromone-Inspired Memory: A rough approach to managing long-term context using weighted relationship graphs and lexical indexing.
The "Mind Protocol" is my attempt to formalize this architecture. I'm curious to hear from others who are moving away from simple "loop-and-prompt" patterns—how are you handling state consistency and world-building for your agents?
I'd love to hear your critiques and thoughts on this approach.
I’ve been a frontend developer for 6 years, and when I first tried to hand my apps over to AI agents, they kept breaking everything.
I realized the problem wasn't the LLM's intelligence—it was our UI "physics." We build UIs for humans who fill in the context themselves. For AI, a button is just a meaningless callback.
I’m proposing a shift from imperative event handling to a Deterministic Coordinate Space. By treating state changes as vectors in a domain space, I managed to:
1. Get consistent O(1) performance (2 LLM calls regardless of task complexity).
2. Stop "Context Drift" where agents forget the original intent.
I've open-sourced the core architecture (Manifesto) and would love to hear what you think about building "AI-native" software environments.
I’ve been debugging LLM-based agents for a while, and I kept running into the same failures:
impossible action loops, irreproducible state, and “I have no idea why this happened” moments.
This post is my attempt to explain why those failures keep happening.
My conclusion is that in most agent systems, the problem isn’t the model or reasoning quality,
but the fact that the “world” (state, rules, action availability) is implicit and lives only in the model’s head.
I wrote about a world-centric approach where:
- the world state is explicit and immutable,
- actions are gated by computed availability,
- and models can only propose changes, never directly mutate state.
I also built a small demo to see if this idea actually holds up in practice.
Happy to hear counterarguments — especially if you think this is just reinventing something
or pushing too much logic out of the model.
This is a 1-page concept describing a formal semantic interface layer
that exposes software state, transitions, and action space to AI agents —
avoiding DOM heuristics and non-deterministic UI behavior.
"OP here. Currently, most agents rely on computer vision (pixels) or raw DOM parsing. I argue that this is insufficient for deterministic B2B use cases because it misses 'invisible' logic (e.g., why is a button disabled?).
This whitepaper proposes a 'Semantic Projection' layer generated directly from the domain model. I'd love to hear your thoughts on this architectural approach.
The author already touched on a better answer. Scenius worked because of the "permission to fuck around." Nobody expected your Arduino to ship. But the conclusion hands you four value-capture strategies and quietly revokes that permission. "Play freely, but collect the exhaust" isn't permission—it's a conditional license.
I once learned songwriting from an indie musician who refused autotune and wrote by hand. He said the point of busking isn't playing because there's an audience. It's playing when nobody stops. You play anyway. That's how you find your sound.
This gets at the root of "evaluative anesthesia." It's not that our tools are too powerful. It's that we're asking "is this valuable?" at every step. A busker doesn't ask that. Taste and judgment accumulate as a residue of immersion, not deliberate capture.
What vibe coding needs isn't a smarter consumption strategy. It might just be the courage to play to an empty street.