Miadi Review

From Prompting to Oversight: Engineering Near-Loop Agent Architectures

Oct 26, 2026 · model: manual-edit · channel: IndyDevDan

Watch sourceView transcript

In the chronicle

From Prompting to Oversight: Engineering Near-Loop Agent Architectures

Source: ELITE Agentic Engineers Are LEAVING THE LOOP... Here’s why — IndyDevDan
https://youtu.be/52JX83rGPLc
relates: oh other video that I have added a review from this YouTube, but I'm subscribed for ha is potentially part of reflection and deep reference on what he's actually creating because we really want to achieve what he's talking about getting out of the loop which we're getting really better but they're probably very interesting inside to the actual content that we will put in this review here. an important insight that I agree with is that we are the human some part of the limiting factor in which when we shall not be in the loop, we shall not be. They raise a question for myself that could probably be inferred from the content here as well as the whole factory that we're building is, where is the place of the human within that loop. dependsOn: the jgwill/medicine-wheel and Miadi Factory to be capable to inventory and organize capabilities , repositories and recently missions related sessions bxecause this implies lots of thes
todo: evaluate if rhe agent is complaisant and make fun of it and enter the loop

question

@miadi/chronicle-tui Tide Cockpit Drafts (mctdraft://)

  • How could human be kept near-the-loop with that ? (a human is drafting like into mia@gaia:tmux://mctgo-2611020738 and another human or agent can know about that by related desire (or existing missions in whatever state they are) and do something about it.

Potential cases

State-Machine: Drafted and not sent and evaluated as over capacity for an agent to resolve by JEV

intentID: 2611020758 status: writing about it and probably some decisions and implementation or revision of missions can be understood with that...

  • The MCTDraft is not sent and implicit/explicit content of the prompt is too complex for an agent to complete or for a human to comprehend
  • ...

Complacency 261028

/Missions in the Factory 2610310251

GUillaume's question and intent draft

  • Will that be a place to keep us near-loop ??
  • How can we, human, participate in making the naming of the mission even more adequate? (So that implication and potential next steps will be taken by the agent as it progresses to the mission like adding on to it ?)
  • Complex but we need to talk about that: How will it relate to Asterion's Plot Thread and the fact that we need structural tension chart in all we do, implying that the agent's mission is necessarely one chart_id of some level (ex. a specific telescope_action_step that the mission definition contains one or many of these steps...) ; Risk: Flattening with TODOList tool -> Mitigation with plugin hooks of TODOList cature that with JEV and an agent we keep the mission on track which increase the risk because we need to negociate with another agent which could be the one that is responsible to interact with the human (to keep the human near the loop, making the one in a mission accountable to that mission pretty much if that is an A2A or Shared Memory State or some whatever fuck I dont know how to call an IntentionGraph that is well organized for ensuring that we can apply this "Agent Commitment Tracking" recently discuss would be a concrete application.
    • Prerequiside is mastering more ⟐ ep 564 Jev decides with the Factory in order to actually use JEV for file potential context reading (which is one part of the JEV Level) and probably others... ⟐ ep 567 Miawa Pascone: the seat decides what to read with Jev, to be ready to write the proposal was created by session 'miawa' which will lead to written article and proposal with concordia, that session is supposed to have explored that aspect of JEV which for the Mission control and the related Charting we would really need sukch engine as well (just evaluating the quality of a Chart Title description and Mission Description so that we have great sets of criteria that makes the EXPECTED SLOPPY descrition automatically revised by a JEV loop that makes evaluating and giviing a score to get named End-result and adequate Observation of current reality (not just big words that are just confused as we often get...)....

Summary

IndyDevDan argues for shifting developer attention from human-in-the-loop prompting to near-loop approval and out-loop autonomous systems. He holds that the human developer is now the main bottleneck, and describes combining durable agents that keep memory, dedicated sandboxes and an API layer for triggers so that multi-step workflows start without a prompt. He says that mastering context, tokenomics, prompt and harness engineering separates agentic engineering from vibe coding, and that the work then happens before and after the human checks in. The examples are his own demos, and the video also promotes the pre-sale of his Phase Three product (22:08-25:15).

Academic Fields

Human Supervisory Control and Levels of Automation (Human Factors Engineering)

This field studies how people supervise automated systems and which functions machines take over. Parasuraman, Sheridan and Wickens set automation levels per function: acquiring, analysing, deciding, acting. The video's in-, near- and out-of-the-loop positions are such levels. Bainbridge's limit: automation leaves people the monitoring and the rare, critical interventions.

Automation Bias and Complacency (Cognitive Psychology)

This field studies over-reliance on automated aids. Parasuraman and Manzey review omission errors, missing what the aid does not flag, and commission errors, following its wrong advice. The video's near-loop step, one human decision on a prepared patch, is where this applies. Limit: experts make these errors, and training does not prevent them.

Event-Driven Architecture (Software Engineering)

This field studies components that react to events, not direct calls. The video's webhooks, cron jobs and log events start agents this way. Fowler separates event notification, state transfer, event sourcing and CQRS. Limit: a flow spread across events is not explicit in any program text, and often only live monitoring reveals it.

Rollback Recovery and Durable Execution (Distributed Systems)

This field studies how computations survive failure by saving state. Elnozahy and colleagues classify checkpoint-based and log-based recovery; log-based methods also record nondeterministic events for replay. The video's durable agents survive crashes and restarts. Limit: the survey assumes fail-stop failures and excludes components that keep running and misbehave, as a model can.

Runtime Guardrails for LLM Agents (AI Safety)

This field studies run-time limits on agent actions. Saltzer and Schroeder's least privilege grants only the access a task needs. The video's sandboxes, removed bash tool and Jev damage control restrict an agent this way. Limit: Greshake and colleagues show injected prompts in retrieved data can override controls, so restricting tools reduces, not removes, risk.

Task-Based Economics of Automation (Labor Economics)

This field studies work as bundles of tasks, some replaced by machines, some complemented. Autor, Levy and Murnane found computers substitute for rule-based tasks and complement nonroutine ones. The speaker's claim that 80% or more of work can run without people is a task estimate. Limit: Eloundou and colleagues rate task exposure, not automation.

Aspects

The Bottleneck Shift: In-Loop to Out-Loop (02:15-03:40)

The speaker names three positions: in the loop (you and the terminal, writing prompts), near the loop (you click, respond and give feedback) and out of the loop (cron, no human required) (02:29-02:51). He says the engineer in the loop is the bottleneck, and that "80% or more" of the work engineers do now can run without them given the right system (03:17). That figure is the speaker's own estimate, as stated in the video. The video gives no measurement behind it.

Reactive Versus Proactive Agent Design (04:10-05:15)

The speaker calls in-loop prompting "yesterday's advantage" and "fully saturated" (04:41). A proactive design starts the agent from a concrete event instead of the developer: a webhook, a cron job, a user action in an interface, or a log event classified by Jev (04:20). Jev is TypeSafe's System One model, which returns typed decisions instead of text. What the agent needs is "information, and it's the right information" (04:56), so he describes the engineer's job as getting the right information to the right agent.

Durable Agents in Isolated Sandboxes (06:00-08:35)

The speaker says near-loop workflows need durable agents that survive crashes, restarts and closed laptops (06:15) and require memory to keep track of everything (08:18). He wants each agent in its own sandbox with its own CPU compute, because it is then always on, isolated and autonomous (06:23-06:37). A clear API layer connects triggers to the system (06:53), and a durable agent plus a trigger in a sandbox gives "a proactive agent" (07:35). The transcript names no database or other store for the memory.

The Core Four Sub-Skills (15:37-18:14)

The speaker names the core four as context, model, prompt and tools (15:37), and restates them at 18:13 as context engineering, tokenomics, prompt engineering and harness engineering. He singles out harness engineering as the one worth most attention at mid and advanced levels, because it wraps the model in a system that can outperform the baseline (16:18). He says the out-of-the-box harness gives everyone the same results, and that specializing is where engineers have the advantage (16:55, 17:37). He says tokenomics matters because current subscriptions are subsidized and will not last (17:04).

Vibe Coding Versus Agentic Engineering (19:07-20:28)

In the speaker's words, "vibe coding is the floor" and "agentic engineering is the ceiling" (19:07), and vibe coding is "not knowing what your system does and it's not looking" (20:13). His example of the other side: choose a model for cost, performance and speed, build a custom harness (he recommends Pi), add Jev as damage control, and perhaps remove the bash tool because it is dangerous (19:18-19:33). He defines agentic engineering as "knowing what your system does so well you don't have to look" (20:13). The transcript gives no test for knowing a system that well.

End-results and Core Aspect

Core Aspect — Near-Loop Proactive Architecture (05:11-06:00)

The core pattern is an AI developer workflow started by an event: detect, triage, patch, ask, apply the change, verify, save results (05:31-05:48). The human enters at the "ask" step and makes a concrete decision. The work before and after that step runs without them (05:11).

Results

  • On-Call Incident Triage and Patching, Shown as a Mock Example (08:43-10:02): For incident response the speaker lists detect, investigate, root-cause analysis, fix and prepare for review, and says a proactive agent can do this so the on-call engineer is "just the reviewer" (08:43-09:03). The UI shown is a mock example: a disconnected client with streaming events, Jev classifying them, and an on-call agent that found the issue and waits for approval before deploy (09:13-09:31). He says engineers are rolling this out, and names none (09:31).
  • Continuous Technical Signal Curation (10:05-11:58): The speaker shows a durable news agent on his M4 Mac mini. He says it has been on for a week and a half, ingests the news, and presents it normalized "in a non-biased way" (10:37-11:08). Filtering hype, facts and signal with Jev was covered in his previous video (10:05). He upvotes items so the agent keeps asking him questions and the "data flywheel" improves (11:19). One running instance is shown. The transcript gives no measure of how much signal it surfaces or how accurate its filtering is.
  • Recursive Design Replication via Deep Jev (12:00-13:55): The speaker calls it "a primitive RSI loop". He drops in a mock design and the loop runs fix, build, screenshot, Jev, with two or more agents optionally, until the UI passes a similarity threshold (11:59-12:28). The tool is the Deep Jev UI Replicator. In one cloud-sandbox run, as he reports it, Astra mirrored a UI and "got a 86.1 match" (13:09). In a second run on a landing page, it reached "a decent result" after iteration three and then failed to improve, and he says the model was Sonnet 5.5 (13:23). He says a run takes about 30 minutes (13:38). The transcript does not define the match score. Both results are his own, from single runs.

Sources