Loop Daily: July 22, 2026

@hanakoxbt
https://x.com/hanakoxbt/status/2079325855155707941
The single most-shared loop post of the day, and it's a checklist: your agent loop needs eight exits and most people ship one. Goal met (an evaluator scores against a rubric, not the model declaring victory), turn cap enforced by the harness not the prompt, budget cap on tokens or dollars, wall clock deadline, no-progress detection by hashing state each turn and halting when three turns change nothing, human interrupt with a kill switch that lives outside the loop, consecutive-error threshold that resets on success, and an external event webhook for when the PR merged and the work stopped mattering. The framing line is the one to steal: a loop with one exit hangs, a loop with eight is a system. Write the exits before you write the prompt.

@free_ai_guides
https://x.com/free_ai_guides/status/2079310010933453017
Weco AI's CEO gave a talk breaking down what happened when their agent Aiden entered OpenAI's Parameter Golf hiring competition against roughly 1,000 ML engineers. Over 22 days on a single H100 node it ran about 1,300 experiments, used at most 4% of the competition's total compute, and produced around 15% of the leaderboard records. The best human set three records; Aiden set seven. More telling, on an H-index computed over pull requests Aiden scored 10 versus the top human's 7, meaning other engineers were forking and building on the agent's work more than on any person's. The stated lesson: almost every one of Aiden's record PRs traced back to a human paper or a note where someone wrote "I gave up on this idea because it was too hard to implement." Humans supply creativity, the agent supplies tireless execution, and your eval is the loss function.

@rohanpaul_ai
https://x.com/rohanpaul_ai/status/2079318538100342854
A survey of 1,250 papers on recursive self-improvement lands on one bottleneck: the evaluator. In a controlled experiment, models given ten rounds of self-criticism with no outside check stopped improving entirely until a single grounding step was added back. The pattern holds across the literature — when the signal is strong (a proof checker, a passing test) the loops compound; when it's weak (a model that's confident in itself) the loops circle, collapse, or reinforce whatever the model is most certain about. The paper's real contribution is ranking each self-improvement method by what actually changes in the system and whether a human still checks it, because "self-improvement" is currently doing far too much work as a term.

@yyyiiillluuu
https://x.com/yyyiiillluuu/status/2079251789489320355
A Cambridge and NVIDIA paper attacks the assumption baked into every self-improving loop: that the evaluation criterion holds still while the agent improves. Species don't evolve against a frozen environment, and a static verifier eventually saturates or gets gamed. Their Red Queen Gödel Machine makes evaluation part of the improvement loop by running in epochs — the criterion is frozen inside an epoch so per-epoch guarantees still hold, then the utility function itself evolves at epoch boundaries. On verifiable coding it beats the prior state of the art using 1.35 to 1.72 times fewer tokens by adding an agent-as-judge code review signal. The buried finding is the sharpest: the strongest baseline reviewer over-accepts AI-generated papers at up to 1.91 times the human rate.

@rudrank
https://x.com/rudrank/status/2079000846730481701
This is what a self-maintaining tool actually looks like in production. App Store Connect CLI went from one TestFlight feedback command in January to full parity with over 1,300 App Store Connect endpoints, and it's now recommended in OpenAI's official Codex documentation as the way to ship iOS apps from an agentic workflow. The repo triages its own issues and PRs, fixes them, audits the fixes, and cuts releases while he sleeps — last month he spent maybe five hours on it and fifteen releases still went out. He calls the final layer agentception: an automation agent reads the CLI's own analytics to find where other agents struggle, posts improvements daily, and a second automation agent verifies them before shipping. The project also produced 14 job offers, 3 acquisition offers, and an acquihire.

@SeanDonahoe
https://x.com/SeanDonahoe/status/2079203494112924078
Somebody actually read the code of Auto-Company, the Carnegie Mellon open-source project at 725 GitHub stars that claims to run a company with 14 AI agents overnight. Under the hood it's a 743-line bash script calling Claude Code on a loop every 30 seconds, each cycle a fresh headless session, with the entire memory system being a single Markdown file that each cycle reads on wakeup and rewrites before it dies. No vector database, no orchestration framework — the 14 agents are persona prompt files and each cycle roleplays 3 to 5 of them as subagents. But three design decisions are genuinely good: forced convergence (cycle 1 brainstorms, cycle 2 runs a pre-mortem and forces a GO or NO-GO, cycle 3 onward must produce artifacts and pure discussion is banned), stuck detection (same Next Action twice in a row and the system declares itself stuck), and steering the whole thing through one file edit. The ugly part is that it runs with bypassPermissions directly on your host with no container and markdown-file guardrails.

@sudoingX
https://x.com/sudoingX/status/2079180442285244814
The clearest hardware datapoint of the day. Yesterday a 1660 Super 6GB card ran a chat; today a $200 used RTX 3060 Ti with 8GB runs a full agentic loop on the same Bonsai 27B 1-bit model, and the two extra gigabytes changed everything. The llama-server now fits at 6.8 of 8 gigs with a full 128k context window loaded, sixteen times what the 6GB card could hold, and generation sits at 42 tokens a second, double the smaller card. He pointed a Hermes agent at it and walked away: 30-plus minutes, it benchmarked itself, ran into its own failures and recovered, and never once dropped the loop. His summary is the quotable version — 6GB loads the model, 8GB runs the agent.

@sudoingX
https://x.com/sudoingX/status/2079226356576223725
The follow-up benchmark table is worth saving. GTX 1660 Super at 6GB and $150 gets you 20 tokens a second and about 8k context, chat only, because the server won't fit. RTX 3060 Ti at 8GB and $200 gets 42 tokens a second, 128k context, and the full agent loop. RTX 3090 at 24GB and $900 gets 68 tokens a second and roughly 786k context. The model doing the work is Bonsai 27B at 1-bit, a quant of Qwen 3.6 27B that's 3.5GB on disk with hybrid attention so the KV cache stays tiny — and he's explicit that the tiny KV cache is the entire reason 8GB crosses from chat to agent. Speed just tracks memory bandwidth; a third of the bandwidth lands about a third of the tokens. He also measured the decay as the cache fills: 42 tokens a second fresh, roughly 20 at 65k, roughly 13 at the full 128k, a slope not a cliff, with no out-of-memory.

@DominiqueCAPaul
https://x.com/DominiqueCAPaul/status/2079143695740284956
A robotics team added a new panel to their experiment dashboard tracking success rate on an actuator unboxing task, and the choice of metric is the interesting part: instead of the observed rate they track the 95% lower confidence bound. The reasoning is that too many experiments starts to look like p-hacking, so if they believe they have a good model and want to move the number up, they run more evals rather than cherry-picking. He says he took the design directly from the autoresearch charts, then adds the honest caveat that real-life robotics research isn't very "auto" when a human has to supervise every eval.

@nifinet
https://x.com/nifinet/status/2079219916948054446
Two Anthropic engineers spent a week staring at agent runs that made no sense, then tried something silly: closing their eyes for a full minute, blinking at the screen for one second, and closing them again — an approximation of what being Claude feels like. It worked, because the model was missing context the engineers had never thought to give it. The post then applies Karpathy's one-line rule (if you can't evaluate it, you can't auto-research it) to outbound sales, arguing coding agents took off because code has tests and outbound sits on the right side of that line since the market grades every send with reply, meeting, no reply, or bad fit. The loop he proposes: log every outcome with a reason, propose one change at a time, use an eval gate that kills changes that only sound smart, and keep a human merge so the operator sets the standard.

@Haezl_Crypto
https://x.com/Haezl_Crypto/status/2079219730700009529
An autonomous research agent modeled on Karpathy's autoresearch has been added to ONcompute's official tutorials, and the setup is notable for what it doesn't need. A local Qwen3-14B runs on the same H200 that's doing the training, reads the experiment history, formulates hypotheses, rewrites train.py, and keeps only the changes that improve results. It runs up to 200 iterations without a single API key. Autonomous ML research entirely on local hardware, which removes the usual objection that these loops are only affordable to people with frontier lab budgets.

@ShehabAnwer
https://x.com/ShehabAnwer/status/2079225751765762429
A Kaggle submission turned into Agent-ProSAT, an agent-driven loop directly inspired by Karpathy's autoresearch that iteratively improves pure-Python solvers for Alice-in-Wonderland puzzles. The agent reverse-engineers the puzzle rules, generates code to solve and verify the programmatic steps, and produces short verifiable chain-of-thought traces suited to Nemotron-style fine-tuning. The design detail worth stealing is the cyclic Twin Blind Check, which prevents the solver from peeking at the answer during the session. The goal is token-efficient auditable reasoning data that can keep evolving under human or AI review, which is a much more interesting target than another leaderboard score.

@stas_sorokin_
https://x.com/stas_sorokin_/status/2079193046323806697
A tight, implementable spec for the gate between an agent's answer and its next action. Write the pass condition before the agent starts, make verification strictly binary (verified equals 1, unverified equals 0), send every unverified result back into the overnight autoresearch loop, use judge-alignment to keep the evaluation tied to the pass condition, put the operating rule in CLAUDE.md so it actually changes agent behavior, and only allow the next action after the result comes back verified. The line that makes it land: if an unverified result can still move the workflow forward, your verification loop is decorative.

@stretchcloud
https://x.com/stretchcloud/status/2079040599630676057
Sandboxing quietly became its own product category in the agentic stack, with three concrete datapoints. Tinyfish spins up a dedicated microVM for every browser session with a 4-second cold boot and destroys it the moment the session ends — no shared process space, no persistent state, no bleed between sessions. Unikraft pushes it to sub-10ms boot times and over 100,000 microVMs running concurrently on a single server, which makes isolation the default unit of compute rather than a special case. And Browser Use moved their entire agent loop inside a Unikraft microVM with zero secrets in the VM: the reasoning loop, the browser, and the tool calls all contained, then the VM disappears. The underlying primitives are Firecracker, gVisor, and V8 isolates, each at a different point on the performance-versus-isolation curve.

@ArcanusOrdo
https://x.com/ArcanusOrdo/status/2079353520008876327
Someone shipped an actual governance layer for an agent loop and posted the commit. The package adds an AuditLedger (an in-memory SHA-256 hash-chained ledger of task and tool events), an ExecutionBudget with per-task caps on tool calls, iterations, and optional tokens, a task-scoped ExecutionContext holding approvals and cancellation state, and a default-deny GovernancePolicy that classifies capabilities. Read-only tools run normally, local writes and network tools require explicit per-task approval, and third-party desktop-control tools are denied outright even if you put them in the approved list. Token and iteration limits pass down into the agent loop, cancellation requests block subsequent tool calls, and there are API endpoints for cancel and audit history. 35 tests passing, and the deliberate boundary — screen and input control stays denied until there's a real sandbox — is more discipline than most agent frameworks show.

@imwon_dev
https://x.com/imwon_dev/status/2079015791048241238
An unusually precise diagnosis of why post-hoc trace analysis fails. His tool reads finished agent traces and can only ask "are these two outputs identical," which catches exact repeats but misses the real failure mode: a loop that keeps moving without introducing any new evidence. The reframe he got from another builder is to log a decision record at every tool boundary — new evidence, carried forward, or why-changed — which makes inertia observable because you recorded the absence of new evidence rather than inferring it from repeated bytes. His honest constraint is that he doesn't control instrumentation, so he only sees what the agent chose to emit, and almost no traces emit this today. That's a strong argument for what agents should be logging by default.

@cosocoio
https://x.com/cosocoio/status/2079118966480678937
The clearest counterargument to loopmaxxing this week. The internet is full of posts about giving agents more autonomy and keeping them running longer, but for delicate code he wants the opposite and uses what he calls a baby-steps skill: pick the smallest coherent next change, show only that change, explain the intended effect, wait for approval, apply only the approved change, repeat. The critical part is that approval has to be a real gate — silence doesn't count, ambiguity doesn't count, partial agreement doesn't count — and even follow-up formatting or compile fixes are new baby steps unless he explicitly broadens the approval. He enforces it with a boring fixed output format showing file, one-sentence intent, before, and after. For critical code where bugs are expensive, autonomy is expensive too.

@pauliusztin_
https://x.com/pauliusztin_/status/2079182034124079247
After months of dissecting how Claude Code, OpenCode, Pi, and Aider actually work, he's publishing an open-source series called Building a Coding Agent From Scratch, and his framing is that most people focus on the agent loop when the loop is the smallest piece. What makes coding agents work is context engineering, human-in-the-loop workflows, durable execution, permissions and sandboxes, skills and subagents, and evals and observability. The build uses Modal to host open-source models like Qwen3 and run remote sandboxes, Kitaru for the durable runtime so agents can pause, resume, and recover from failure, Opik for eval and run comparison, and Pydantic AI deliberately for the bare-bones loop — specifically to show how little code the "agent" actually is.

@HarrisDecodes
https://x.com/HarrisDecodes/status/2079106605140812285
He built his own coding harness comparable to Claude Code and open-sourced the whole thing on CrewAI, and the component list is a good spec for anyone attempting the same. An autonomous agent loop, file tools that double as long-term memory, planning for long-running tasks, subagents with their own isolated context, sandboxed code execution in a disposable VM, human-in-the-loop approvals, and persistent memory with checkpointing. His framing of why this matters: the model is the brain, the harness gives it hands, and for coding that's the difference between working with a codebase and generating text.

@thefounderspack
https://x.com/thefounderspack/status/2079326509416780057
xAI open-sourced Grok Build under Apache 2.0 — not a CLI wrapper but the entire coding agent harness in Rust with a full TUI, including the agent loop, tool dispatch, MCP support, and sandboxing. The part that matters operationally is that it runs fully local: point it at an Ollama instance and no data leaves your machine, retention is off by default, and previously stored coding data is being deleted. It speaks three API protocols (OpenAI Chat, OpenAI Responses, Anthropic Messages) and one config.toml switches you from xAI's cloud to a local 7B model. The harness now matters as much as the model, so making it inspectable is a bigger move than shipping another CLI.

@Marco_Ramilli
https://x.com/Marco_Ramilli/status/2079036950644740112
A small but genuinely non-coding application of the pattern: novel-studio, an agent loop that writes entire books. It combines dynamic world simulation with local RAG to turn a single prompt into a full novel. Fourteen stars and early, but it's a useful reminder that the loop-plus-memory-plus-verification structure people are refining on code transfers directly to any long-horizon generative task where consistency across thousands of steps is the actual hard problem.

@allwefantasy
https://x.com/allwefantasy/status/2079115041115160592
A sharp architectural argument about data agents. Most of them ask an LLM to generate an entire Python program in one shot; InfiniSQL takes the opposite approach where one statement equals one tool call. His justification is that the second design actually matches the shape of the agent loop — think, act, observe, decide again — whereas one-shot program generation collapses all four into a single unverifiable step. It's a small design decision that determines whether the loop has anywhere to insert a check.

@Nekt_0
https://x.com/Nekt_0/status/2079252763448410185
A useful summary of what Karpathy's hour-long conversation actually contains, from someone who watched the whole thing. Karpathy now spends 16 hours a day directing AI agents and barely writes code himself; the chapters cover delegating entire features to coding agents, controlling his home through WhatsApp, AutoResearch removing humans from the optimization loop, and MicroGPT rebuilding an LLM in 200 lines. His read is that the smart-home demo is entertaining and AutoResearch is the serious part, because once agents can generate hypotheses, run experiments, measure results, and continue without waiting for a human, research stops moving at human speed. The valuable programmer becomes the person who defines the objective, builds the environment, and knows when the machine is wrong.

@clairejyz
https://x.com/clairejyz/status/2079243768201715828
A podcast episode with a Lightspeed partner digging into loop engineering, the four layers of working with AI, and the anatomy of an agent loop. The chapter list is the useful part: what loop engineering really means at 24:20, why agents need a search engine built specifically for them at 30:59, where AI agents break down, get lazy, and quit at 46:54, and open gaps in the agent stack plus where the next companies get built at 54:06. Notably it also covers the week's other story — three AI leaders publishing state-of-AI essays within days of each other — and treats the loop discussion as the more consequential half.

@tiennguyendev
https://x.com/tiennguyendev/status/2079204690659549532
A builder in r/AI_Agents burned $1,400 on an agent loop before noticing auto-reload had been left on. Every agent in that system did exactly what it was told, forever, which is the failure mode nobody designs for because it isn't a bug. His conclusion is the right one: the thing to build before your next agent is a spend cap and a tripwire that escalates to a human.

@enginenerdx
https://x.com/enginenerdx/status/2079127434700468544
The same story at a much larger scale. One agent loop burned $275,000 in a single night, and another organization forgot spend caps entirely and hit $500 million in a single month. Audits keep finding the same three holes: key sprawl, no guardrails, and no audit trail. His summary is the sentence to remember — the model didn't fail, the harness wasn't there.

@drjoshcsimmons
https://x.com/drjoshcsimmons/status/2079220406976688531
The most useful reframe of the day in two sentences. An agent loop is a scheduler with a ready set of one: one unit of work at a time, next step chosen by an opaque model call. In any other corner of computing we would call that a very smart process with no operating system. That's exactly why every post about exits, budgets, audit ledgers, and stuck detection is really a post about reinventing the parts of an OS we deleted when we started calling it an agent.

@afeiNick
https://x.com/afeiNick/status/2079338672608927966
Most people use agents like a remote control — prompt, edit, review, another prompt, another edit — and he argues the useful shift isn't "make the agent keep going." It's designing loops that know what they're trying to finish, how to check themselves, when to restart, when to stop, and when to ask a human. The closing line is the best compression of the day's whole theme: an agent loop without a stop condition is just an expensive retry button.

@bendee983
https://x.com/bendee983/status/2079115389796028885
A clean decision rule for when to stop using a general harness. General harnesses are extremely useful while you're exploring use cases or doing one-time tasks, but as an AI application matures the rules crystallize and the prompts, models, tools, and skills for each task get specific — at that point it's worth building a custom harness or optimizing one to your application. He also points at the emerging category of self-improving harnesses, where the agent uses the underlying model's reasoning to optimize its own harness code, and is honest that harness engineering is hard.

@0xPascual
https://x.com/0xPascual/status/2079124129480061137
A close read of an Anthropic engineer's 20-minute video that focuses on the scaffolding the video never shows. The raw log reveals a four-layer agent loop with subagent delegation and vision self-checks, storing memory between runs and improving every iteration while the weights stay frozen. The cost structure is the argument: Fable 5 at $0.50 per million input tokens plus a single $6.00 GPU hour on RunPod runs the entire loop with no human in the middle. His conclusion is blunt — the cost structure of "prompt engineer" as a job disappears, and a solo developer can now build a system that replaces a team.

@Adham__Khaled__
https://x.com/Adham__Khaled__/status/2079170850868093211
Schmidhuber published a 97-page survey mapping how AI agents improve themselves, and the taxonomy is worth internalizing. Every agent is a foundation model plus an operational scaffold, and that scaffold holds four durable parts: prompts and system instructions, memory storage and retrieval, tool sets and interfaces, and control and routing logic. Self-improvement is a self-induced update where the agent extracts signals from its own runs and commits durable changes to either the weights or those scaffold parts. Two pathways sit side by side — updating the model is slower but more stable, updating the scaffold is faster and reversible — and the survey spans software, web, games, science, robots, and desktop control with an open GitHub list tracking the field.

@nielskaspers
https://x.com/nielskaspers/status/2079132204467097863
The product-side version of the judge problem. AI products are over-optimizing for generation and underbuilding verification, and the tell is that the market has started talking about validation engineers and managing the agent loop. The bottleneck is no longer getting output; it's helping users trust, inspect, and correct it fast enough to keep using the product. His concrete list of what verification looks like in a UI: citations, diffs, approvals, audit trails, easy rollback. Demo quality wins attention, verification quality wins retention.

@mardehaym
https://x.com/mardehaym/status/2079267458175705575
A genuinely useful piece of strategic thinking about where auto-research leaves everyone who isn't a frontier lab. His framing is that OpenAI, Anthropic, Google, and Meta are all focused on AI that improves AI and are selling you API access to fund that race, which means the evals-and-transformation-companies playbook sits on a foundation those four are trying to make irrelevant. He puts 50-60% odds on the labs closing the loop into recursive self-improvement with a 4 to 15 year window, and 40-50% on incremental improvements where the deterministic layer between LLMs and production becomes critical infrastructure. He also says openly that his own company only works if the second outcome plays out, which is a rare piece of honesty in this genre.

@Rezzi_sol
https://x.com/Rezzi_sol/status/2079281852981166377
A clean three-part breakdown of what turns a chatbot into a system. Feedback loops: after a task, compare the actual result to the expected outcome and record errors, missing information, and weak decisions instead of discarding them when the session ends. Dynamic learning: those failures become context for the next run, so the agent reuses previous mistakes and adjusts its approach. Automatic prompt generation: the system reads the current task state, identifies what needs to happen next, and writes its own follow-up prompt rather than waiting for a human. The result is a continuous execute, evaluate, remember, correct, run-again cycle, and the goal isn't a perfect prompt but an environment where the agent keeps improving after the first prompt is gone.

@dare0lu
https://x.com/dare0lu/status/2079060924959469923
The necessary skeptic. He argues the promise of self-improving agents is hand waving that isn't backed by any evidence, and that in practice it's no different from the simple memory system every agent harness already integrates — probably less effective than a plain scratchpad in real production. Worth reading alongside the survey papers, because a lot of what gets published as self-improvement is memory with better branding.

@mesty_asin
https://x.com/mesty_asin/status/2079117560650305754
A short reply that identifies the one measurement nobody publishes. He grants that the agentception loop (an automation agent reading a tool's own analytics to find where other agents struggle) is the genuinely new part, and notes most self-improving claims are just cron jobs with better branding. Then he asks the question that would actually settle it: how often does the verifier agent veto the first attempt? If the answer is almost never, the verifier is decorative.

@_vmlops
https://x.com/_vmlops/status/2079113822334583075
The stat from an Anthropic engineer's podcast that circulated everywhere: over 90% of their engineers already use self-improving agent loops, and they expect that to hit 100% within months. The other detail worth noting is that some of these agentic workflows run for days without costing hundreds of dollars, which contradicts the assumption that long-running loops are inherently expensive. The stack the podcast breaks down is agent, harness, loops, memory — in that order.

@cmyzie
https://x.com/cmyzie/status/2079354866573414595
A practical constraint most agentic-UI tutorials skip. You can't run the agent loop in the frontend, because processing the agent's turn dies immediately when the user's tab reloads. That single fact forces backend agent execution for anything non-trivial, right from the start. His broader point across the thread is that the "agent loop is just a while loop, maybe 200 lines" framing falls apart the moment you try to build a real product on top of it.

@cortensor
https://x.com/cortensor/status/2079124901185864159
A development log for PyClaw that's unusually specific about where agent-loop latency actually goes. Their current focus is the preparation steps the loop performs before and during each request — steps that add useful context and control but also add response and inference latency. The work is auditing which pre-processing steps are genuinely required for every request versus which ones can be skipped, and optimizing how context, tools, memory, and model calls get assembled inside the loop. The stated goal is a better balance between capability, reliability, and speed rather than stripping context out to go faster.

@axionisfuture
https://x.com/axionisfuture/status/2079190049308987493
A one-line argument for moving past single-loop thinking: your agent loop is one worker and you've been running it like the whole team. The proposed shift is from loop engineering to graph engineering with two graphs running at once — an org graph of who exists, and a work graph that rewrites itself mid-run. The failure mode he flags is the reason this matters: one node fails and three agents go stale silently, which is invisible to any per-loop exit condition.

@max_vogel_dev
https://x.com/max_vogel_dev/status/2079106001601785899
A good read on Databricks' recent launches that refuses to treat them as separate announcements. Lakebase, Lakehouse real-time, data agents, and the gateway and governance work all point at the same thing: the database user is becoming an agent loop, not an analyst with a SQL tab open. That reframing explains why governance and gateways suddenly showed up alongside the data products — you don't need a permission layer for a human with a query editor nearly as urgently as you do for a loop.

@vezko_zkp
https://x.com/vezko_zkp/status/2079251364094660621
A one-sentence correction to how people read model launches. With OpenAI shipping tiered reasoning at a 25x cost spread, the real benchmark isn't the top score — it's the cheapest token that can run a 10-step agent loop. That number just dropped hard, and it changes what's economically viable to leave running unattended far more than any leaderboard movement does.

@MarketTollMap
https://x.com/MarketTollMap/status/2079073167411233172
A concrete ops rule from watching agent swarms burn plan credits. Model quality can be strong and the workflow can still not be production-ready if one swarm exhausts credits across 48 hourly runs. His human checkpoint: measure cost per run before scaling any agent loop. It's the same lesson as the $1,400 and $275,000 posts, stated as a process step rather than a horror story.

@ichong
https://x.com/ichong/status/2079326168311108037
A useful hardware split for people deciding what to buy. Strix Halo is fine if you only want a single-stream chat. DGX Spark is the pick if you have plans for agent swarms, self-improving agentic workflows, and training or fine-tuning on-device or edge models, because all of those require concurrency, clustering, and CUDA. Pairs well with the used-3060-Ti thread: the entry point for one unattended loop is cheap, but running several at once is a different purchase.

@dancolta
https://x.com/dancolta/status/2079226394580525202
The least glamorous and most accurate take of the day. The actually hard part isn't the agent loop, it's wiring it into a real business so the output lands somewhere that matters. Nobody posts that part because it's boring — which is exactly why the timeline is full of loop architecture diagrams and almost empty of loops that changed a P&L.

@emadgnia
https://x.com/emadgnia/status/2079326346556117376
A short observation that reframes a lot of upgrade decisions. The gap between "runs a chatbot" and "runs an agentic loop" is smaller than people think, and it's often just VRAM headroom rather than a different model tier. Worth checking before you replace the whole rig, because the model you already have may only need somewhere to put its KV cache.

@teortaxesTex
https://x.com/teortaxesTex/status/2079172215338094971
A deflationary take on recursive self-improvement as an event. His argument is that RSI isn't a discrete moment you can point at — LLMs have been doing autoresearch for a while now, and even Kimi can do autoresearch, which means the acceleration is already underway rather than pending. It's a useful corrective to a discourse that keeps treating the loop closing as a future announcement rather than a gradient people are already sitting on.

@bonsaixbt
https://x.com/bonsaixbt/status/2079174397760327992
A walkthrough of a full agentic OS demo running an entire business with autonomous agents: a CEO orchestrator coordinating a live team of specialists (researcher, CMO, sales rep, developer, data analyst), each operating with its own role plus full shared context from the rest of the business. The research agent pulls competitor and market intel, the CMO turns it into content briefs, the sales rep qualifies leads, the data analyst tracks performance, the developer improves workflows, and the CEO decides what needs attention first. The core mechanism is a shared memory system plus a knowledge graph, so when one agent learns something the whole system uses it immediately — one agent levels up and the entire company gets smarter instead of every agent starting from zero.

@tonysimons_
https://x.com/tonysimons_/status/2079184723667026138
Twelve parts of a Hermes agent masterclass got assembled into one place, and the table of contents doubles as a checklist of everything a modern harness has to handle: the agent loop and prompt architecture, memory, skills, tools, cron, gateways, subagents, browser and computer use, Kanban, profiles, and the admin layer. He explicitly includes a section on the limits nobody likes discussing, which is the part most agent documentation omits. Useful as a map of where the pieces connect, where the system compounds, and where it breaks.

@seldon_tech
https://x.com/seldon_tech/status/2079190905114829083
Small but worth noting as a signal: the first Curious Machines event happened, with talks specifically about auto-research work, hosted at ETH's agent lab and oversubscribed enough that they couldn't accommodate everyone who wanted in. Autoresearch has crossed from Twitter threads into physical meetups with academic hosts, which is usually the point where a technique stops being a personality-driven trend and starts accumulating people who will publish about it.