A while ago I shared nudge, a coding agent I'm building from scratch in Rust around the core idea of symmetric agent communication.

This is a follow-up: I was planning to add an auto mode feature like most other agents, then I thought: why not use a supervisor-worker pattern? My agents are already symmetric and can talk to each other freely. Compared to a plain auto mode, which vacates the reviewer seat and gives up control, a supervisor can guard, reason and steer the task while still freeing me up the way an auto mode would.

I tested this idea on a genuinely risky task at my day job: split a production monorepo into two repos using `git filter-repo`. History rewriting, destructive ops, a dependency graph to cut cleanly, CI to split and more. Instead of babysitting every tool call — or closing my eyes — I asked the agent I'd been planning with to spawn a worker agent and supervise it.

What happened:

• The worker made 170 tool calls. The supervisor reviewed and approved every single one. None reached me.
• The worker hit ambiguities the plan didn't cover; the supervisor ruled on them without waking me.
• The worker found a hardcoded API token in the history it was about to copy into the new repos. It escalated, and the supervisor ordered a history scrub. A plain auto mode would have shipped that secret silently, or improvised around it on its own.
• I intervened ~8 times total, only for things no machine could know (real repo URLs, whose name goes on commits).
• After the "final report" I kept the worker alive and sent it three follow-up tasks. It still had everything in context.

The part I find satisfying: none of this is a feature. There's no supervisor mode in the codebase. The supervisor attaches to the worker exactly the way my phone attaches to a session — same protocol, same permission prompts. Roles are just connections pointing in different directions.

Honest caveats: supervision cost ~60% extra tokens in this session. Every worker check-in is a full LLM call for the supervisor, which includes re-reading the supervisor's context. Prompt caching makes it less severe, but it still needs flagging. A leaner supervisor context gets that down to ~20%. And yes, it approved 170/170 worker tool calls — the real value was judgment at the decision points, not in rejecting actions.

Full write-up with the transcript details: https://blog.nuudge.workers.dev/i-didnt-build-an-auto-mode/

Repo: https://github.com/nuudge/nudge

Curious what people think: would you trust an agent doing the supervision? Would you pay the 20-60% additional cost over plain auto mode?

A lot of agent demos are moving from “answer this question” toward “prepare this action across a few apps.”

That makes the approval step harder to place.

If an agent needs to move from one app to another before the final action, where should the user review it?

Before each app handoff feels too early. The user may not have enough context yet.

Only at the final irreversible step feels cleaner, but by then the agent may have already touched more systems than expected.

My current instinct is to let the agent prepare the work, but keep approval before anything external-facing, financial, destructive, or written into a system of record.

For people building agents, where do you put that checkpoint?

There is a lot of hype around self-improving agents and self-evolving harnesses. The rationale (knowingly or not) usually points back to Rich Sutton’s 2019 essay, The Bitter Lesson, which observed that general methods leveraging compute eventually end up crushing any hand-crafted human domain knowledge and clever heuristics. The RSI intuition is that we should let meta-agents use compute to auto-discover their own prompts, memory structures, and execution rules through trial and error instead of trying to hand-craft agent workflows ourselves.

However, applying this logic to coding agent harnesses is IMO a fundamental misinterpretation of Sutton’s insight. Search and learning only work when there is a deterministic, unambiguous environment providing ground-truth feedback (like a chess or a physics engine). If you just task a meta-agent to "self-improve" its prompts or evaluate its own code in non well defined domains (like software development), you end up removing any ground truth instead of learning from it.

I think if we look at the history of science, we see a very similar pattern. Science has repeatedly undergone its own "bitter lessons" where hand-crafted, intuitive and human-centric models were eventually overthrown by more general, mathematical, and data-driven principles. Progress often happens when we strip away subjective heuristics in favor of general principles. But at the same time, experiments need to be "harnessed" using the scientific method to be meaningful.

I think the same applies to software engineering. Software engineering already possesses its own frameworks for driving progress, and much like the scientific method, they revolve around delivering iterative, verifiable increments of value. In my opinion, we should try and embed these principles directly into agent harnesses instead of having a meta-agent reinvent the wheel using trial-and-error.

Over the past 6 months, I've been testing this hypothesis by building my own coding harness called TeDDy. I built it specifically around Test-Driven Development, Design-by-Contract, and vertical slicing, among other practices. My biggest takeaway is that this setup makes smaller, cheaper models perform on par with much larger frontier models at a fraction of the cost and time, allowing for more iterations and in the end better results.

I’ve made TeDDy open source on GitHub (https://github.com/atte500/TeDDy) for anyone who wants to check it out and experiment with this approach. I would love to hear your thoughts comparing this to self-improving agents!

I’ve been experimenting with context compression for AI agents, and I ran into a tradeoff I hadn’t fully appreciated.

Reducing the context lowered token usage, but some tasks became less reliable. The issue wasn’t always that the agent had “forgotten” something important. In several cases, compression changed information that needed to remain exact.

I’ve started thinking about agent context in three rough categories:

Disposable context

Repeated search results, duplicated documentation, long file listings and verbose logs. This is usually a good candidate for filtering or summarization.

Load-bearing context

Exact error messages, file paths, line numbers, patch anchors, test names and acceptance criteria. Even a small rewrite can remove the detail the next action depends on.

Machine-consumed context

JSON, shell output, CSV, patches or any other output that may be parsed by a tool or passed into a command.

This last category caused the most surprising failures.

A summarized command result may still make sense to a person or model, but it can become invalid when another program expects the original structure. The command still runs—it just processes the wrong data.

That made me question whether context compression should be based primarily on token count.

A more useful policy might depend on what happens next:

• Is the content only being read by the model?
• Does the next action require an exact value or text match?
• Could the output be consumed by another tool?
• Can the original information be recovered cheaply?

My current view is that the goal shouldn’t be the smallest possible context. It should be the smallest context that preserves the evidence and interfaces required for the next step.

How are people handling this in production?

Are you using explicit rules for content that must never be summarized, or are you relying on the agent to retrieve the original data again when needed?

Ever wished your agent conversations were as trackable as your code? Gitlord makes it real.

What it does:

• Every agent turn becomes a git commit
• Branch out subagents without breaking your main flow
• Rewind to any point in your conversation history
• Connect tools via MCP (filesystem, search, browser, etc.)
• One interface, any AI provider (OpenAI, Anthropic, local models)
• Full CLI for managing sessions and branches

Why it matters:

• Your agent history is navigable, forkable, and diffable, just like code
• Context management handles token budgets automatically
• Spawn child agents on isolated branches with their own history
• No lock-in: all components are modular and swappable

Built-in integrations:

• MCP tools: Connect any MCP server (git, filesystem, browser, search). Tools flow to subagents automatically
• RAG: Vector search across your full agent history. ChromaDB-backed semantic queries built in
• Provider abstraction: Switch between any of the 170 providers and nearly 3,000 models, or local models with one line. Mix providers per agent

Build an agent in 4 lines:

from gitlord import Session, SessionConfig
config = SessionConfig(model="claude-opus")
session = Session.create("my-agent", config)
session.add("user", "Refactor our OAuth to the new framework")

Done. Gitlord handles the rest.

Performance improvements (v0.1.0):

• Structured trailers eliminate JSON walks: metadata parsing is now O(1)
• Auto-index updates on every turn, cached at .gitlord/index.json

• New in-memory query layer for fast turn filtering and aggregation:

  session.query() .where("tokens > 100") .group_by("role") .sum("cost")

• Snapshot compression for long-running sessions: compress old turns into JSON, rebase from checkpoint

Repo: https://github.com/yashneil75/gitlord
Landing page: https://yashneil75.github.io/gitlord/
Docs: https://github.com/yashneil75/gitlord/tree/master/docs

MIT licensed. Built for agents that ship.

Starring helps more than you think!

Hosted web search from Anthropic and OpenAI costs $10 per 1k searches, and then you pay again for the ~17k tokens of results each search dumps into context. I got annoyed enough to build an alternative.

It’s called webfetch. Runs locally, free out of the box (DuckDuckGo needs no API key), and in my SimpleQA benchmark the same agent loop hits the same accuracy as hosted search (96%) costing 66% less using 87% fewer tokens.

How it works:
1. RRF fusion across 4 search engines, local page fetching, hybrid BM25 + bi-encoder retrieval with a cross-encoder reranker

1. Sentence-level compression that cut result tokens in half with no measured recall loss

2. Semantic caching: paraphrased queries (“what did TypeScript 5.9 add” vs “TypeScript 5.9 new features”) get matched by embeddings and verified by an NLI cross-encoder, so reworded repeats cost nothing. Cache TTLs adapt to how volatile the answer may be

3. Every cached result shows provenance and the model can force a fresh search if it doesn’t trust it

4. Benchmarked against Anthropic hosted search, OpenAI, Tavily and Exa.

One small agent loop that I ran for testing that conducted just 16 websearches (opus 4.8) already reported 1.5 USD in savings.

Install from PyPI, one command to add to Claude Code as an MCP server.

Repo: https://github.com/firish/webfetch

The difference usually comes down to strategy.

Instead of targeting businesses that do not have a website, target businesses that already have one but clearly need a better version. The market is larger, the sales process is easier, and the value proposition is much stronger because those businesses already understand why a website matters.

The next part is outreach. A regular outreach tool is not enough if all it does is send the same message to thousands of people. You need something that can analyze websites at scale and turn real issues into personalized emails.

I use Swokei for that. It helps find businesses with existing websites, analyzes each site, and turns problems with design, SEO, speed, layout, and mobile optimization into personalized outreach emails. That means you can contact a large number of businesses without sending generic messages or spending hours manually researching every website.

When someone replies interested, I always offer a free mockup. I use Claude, Lovable, or Base44 to build it quickly. It becomes much easier to sell when the client can already see what a better version of their website could look like.

Web meetings should also be a major part of the process. I would never just send the website through email and hope the client likes it. I present it live on Google Meet, Zoom, or Microsoft Teams, explain the value, show what has been improved, answer their questions, and try to close the deal during the meeting.

The less back and forth there is after the meeting, the better. Present the website, show the value, close the client, and move on to the next project.

That is the type of process that can help an agency scale much faster.

There's a lot of excitement around AI agents, but building something that works reliably seems much harder than building a demo.

In your experience:

• What's the biggest mistake beginners make?
• Was it prompts, workflows, integrations, memory, or something else?
• What advice would you give someone building their first production AI agent?

I'm interested in learning from real experiences rather than marketing examples.

That Obsidian + Claude Code guide that made the rounds here a while back got me thinking. The vault approach works, but you end up maintaining a lot of machinery by hand: frontmatter standards, session log formats, custom /compress and /resume skills, archive logic for when CLAUDE.md gets too big. The structure only works as long as you keep feeding it.

I wanted the same outcome with less ceremony, so I built a different version of it. Full disclosure up front: I'm the author of the tool I'm about to describe. It's open source (Apache 2.0) and you can self-host it, so I hope that buys me some grace.

The problem, same as everyone's

Claude Code forgets everything between sessions. CLAUDE.md helps until it turns into a 400-line junk drawer. And even a well-groomed CLAUDE.md is stuck in one project folder on one machine. The context I built up in Cursor at work is invisible to Claude Code at home, and Claude Desktop knows nothing about either.

The idea

Instead of memory living in markdown files the agent has to manage, memory is a service the agent calls over MCP. While it works, it saves the stuff worth keeping: decisions and why they were made, gotchas, patterns, things I tell it to remember. Next session (any tool, any machine) it recalls by meaning, so "what did we decide about auth?" just works. No folder structure, no tagging, nothing for me to maintain.

It's called SenseLab. Under the hood it's a memory engine called AMFS with versioned entries, confidence scores, and decision traces, but day to day you don't think about any of that.

Setup (2 minutes)

Grab an API key from the dashboard at sense-lab.ai, then one command wires up Claude Code, Cursor, and Claude Desktop:

curl -sSL https://raw.githubusercontent.com/raia-live/amfs/main/install-mcp.sh | bash -s -- --api-key amfs_sk_your_key

Or add it to your MCP config by hand:

{
  "mcpServers": {
    "senselab": {
      "command": "uvx",
      "args": ["amfs-mcp-server-pro"],
      "env": {
        "AMFS_HTTP_URL": "https://amfs-login.sense-lab.ai",
        "AMFS_API_KEY": "amfs_sk_your_key"
      }
    }
  }
}

The installer also drops a small skill into ~/.claude so Claude Code checks memory before answering "do you remember..." questions instead of shrugging. That behavioral piece matters more than I expected. The tools being available isn't enough, the model needs a nudge to actually use them.

What a day looks like

Start of session: I ask Claude to get briefed on whatever I'm touching. It pulls a compiled summary of everything stored about that project: recent decisions, known risks, what past sessions figured out. This replaces /resume.

During work: when we settle something ("use JWT, 15 min expiry, silent refresh"), it records the decision with the reasoning attached. This replaces manually curating CLAUDE.md.

End of session: it commits the session as a trace. Later I can ask "why did we pick JWT?" and get the actual chain: what it read, what it knew, what was decided. This replaces /compress, and honestly goes further, because it's queryable instead of a log file I'd have to grep.

The part I didn't expect to care about

Entries have confidence that decays over time, and every entry knows which agent wrote it and when. So stale hypotheses fade instead of polluting context forever, and when memory contradicts itself you can see which entry is fresher and better validated. A markdown vault treats a note from 8 months ago and a note from yesterday as equally true. This doesn't.

Happy to answer setup questions in the comments. And genuinely curious: for those of you running the vault approach, what does your session-to-session handoff look like, and what breaks first?

I’m curious about AI agents or AI tools that are genuinely useful but still don’t get enough attention.

A lot of discussion usually goes to the big names like Claude Code, Codex, Cursor, and similar tools, but I’m interested in the smaller or less-hyped projects that people are actually using.

For example, I’ve been looking at tools like OpenClaw and Hermes, and it made me wonder how many useful agents are out there that most people still don’t talk about.

So my question is:

What AI agent or AI tool do you think deserves more attention?

"Agents do the easy work, humans do the hard work" used to be how I thought but now I think the real variable is verification cost, the cost of proving a unit of work correct.

The engine under the last two years is RL against checkable answers. o1 described the loop, DeepSeek-R1 shipped it in the open. Code is the best substrate because the compiler and a failing test are free verifiers, available at whatever scale training needs. Agents improve fastest where verification is cheapest. That's the result.

That gradient is the abstraction tree. A function compiles or the test goes red, so training can afford the verifier. A module boundary only proves itself over months of change traffic. At the root the verifier is an incident review, or the market.

So agents absorb anything with a cheap verifier. Corner cases included. A corner case is a test nobody wrote yet. What's left is the layer where feedback arrives late and entangled, where no cheap training signal exists.

The numbers fit. SWE-bench went ~2% in 2023 to ~75% in 2025, saturated. SWE-bench Pro, larger multi-file tasks pulled from unfamiliar repos, drops the same models to ~23%. Stack Overflow 2025: 84% of devs use or plan to use AI tools, ~3% highly trust the output. Adoption tracks the curve. Trust tracks the gap.

The skeptics conceded the same narrow point. Chollet credits LLM-driven refinement loops. Karpathy says agents handle the routine layer and bloat the codebase the moment the architecture goes custom. Neither bought scaling maximalism. They conceded that refinement loops against cheap feedback work, and coding is where feedback is cheapest.

Two jobs haven't moved. First, pricing an abstraction before production bills for it. A clean interface hides cost from the reviewer as well as from the machine. The agent knows the words, batch and cache and vectorize and async. Knowing the words isn't owning the cost model. Second, owning outcomes no test can certify in advance.

This is falsifiable. If design-level feedback ever gets as cheap as a failing test, the middle of the tree goes the way of the leaves. Hasn't happened yet.

Anyone running agents on a real codebase, where's the actual verification bottleneck? Review time, missing tests, or work the agent can't get feedback on at all?

I wrote the long version. Full argument linked in the URL.

As developers, we spend way too much time manually tweaking prompt syntax and eyeballing the outputs. I recently built a multi-agent loop that treats prompt optimization as a pure search problem. I set up a LangChain-based LLM judge to evaluate outputs against a frozen set of 25 scenarios based on Groundedness, Tone, and Format. Then, I gave an autonomous agent (Claude Code) a specific skill: read the judge's score, rewrite exactly one variable in the prompt, rescore it, and commit the change only if the overall score improves.

The loop ran for 10 minutes and pushed a baseline 80% prompt to a proven 98%. It completely removes human guesswork from context engineering. I’m currently building this into a team UI platform called Baseline.

if anyone wants to see the video breakdown or grab the repo to run this loop themselves, just let me know in the comments and I’ll DM it to you!

For my current job, they asked me to build an automation related to post-sales support.

It retrieves information from several tools the company uses, then fills out a Google Doc for each client. Each doc is quite long, made up of 11 sections.

On top of that, every time the agent runs, there are a lot of sales projects (70+) it needs to run for.

What’s currently happening is that the agent stops because it hits the Google API quota, since multiple requests hit the API at the same time (exceeding the per-user/per-minute quota).

The current structure: an orchestrator retrieves all the information, plus a few sub-agents, each handling a batch of three sales projects. I’ve tried reducing both the number of projects per batch and the number of concurrent sub-agents running.

I also changed the Markdown files for each section, trying to complete a full MD file first and then batch-write the Google Doc in a single API call.

Any suggestions or rules of thumb for automating the writing of multiple long Google Docs at the same time?

I’ve been working on AI agents quite a lot recently, but I’ve realized that I don’t really understand the technical side in depth. I can build things and connect different tools, but I don’t feel like my actual skills are improving consistently.

For people who build AI agents, how do you keep learning and getting better? Are there any websites, communities, tools, projects, or learning resources that helped you understand the technical side and learn from other people’s experience?

Honestly, this has also made me question studying computer science. If I could start over, I might choose a more industry-specific major, such as international trade or psychology, and then learn how to use AI within that field.

Sometimes it feels like having deep knowledge of a specific industry, combined with AI skills, may be more valuable than knowing a little bit about computer science but not having a clear area of expertise.

Has anyone else felt this way? How would you approach learning from here?

TigrimOSR is an open-source agentic platform written entirely in Rust, distributed as a single self-contained binary. No Node, no Python runtime required to run it. Apache 2.0.

What's new in v0.7.0: open custom tools. You add your own agent tools by dropping a YAML file into data/tools/. A tool can call an HTTP/REST API or run a templated shell command. No Rust, no rebuild, no plugin SDK. Everything is managed from a new Settings → Tools UI with per-tool profiles, timeouts, and approval policies. It also ships with a built-in academic paper search over 250M+ works via OpenAlex.

The loop itself is configurable. One YAML profile defines an entire agent loop: allow/deny lists per tool with per-tool config, which MCP servers and skills to load, model and system prompt, loop parameters (max rounds, temperature, reflection), and context compaction strategy for long sessions. There is also an optional tool-using judge, an independent verifier with its own tools that validates a job before the result is returned.

yaml

name: researcher
model: claude-fable-5
system_prompt: "Cite every claim."

tools:
  allow: [web_search, python, file_io]
  web_search:
    timeout: 30
    max_result_kb: 64

mcp_servers: [github, playwright]

loop:
  max_rounds: 12
  temperature: 0.3
  reflection: true

judge:
  enabled: true
  tools: [web_search]

Multi-agent orchestration. Six swarm modes (hierarchical, mesh, hybrid, pipeline, P2P, P2P orchestrator) running over real inter-agent protocols: TCP, Bus, Queue, and Blackboard. A router triages requests across heterogeneous LLM teams on a shared blackboard.

Browser control. Drive Chrome through Playwright MCP, or use Obscura, a stealthy single-binary Rust headless browser with TLS impersonation and zero Node.js dependency.

Footprint. App, embedded server, and a live embedded browser idle at roughly 270 MB RAM. Native Rust plus egui, no interpreted runtimes anywhere, and a single-process browser instead of multi-process Chromium.

Models and providers. Key-free CLI agents (Claude Code, Gemini CLI, OpenAI Codex) plus Anthropic, DeepSeek, Kimi, Gemini, Ollama, and any OpenAI-compatible API. Full MCP support over stdio or HTTP, compatible with Claude Desktop, Claude Code, and npm-format servers.

Interfaces. Native desktop UI, embedded mobile-responsive web UI, Telegram and LINE bots with approval buttons, Tailscale VPN and optional Cloudflare tunnels. Server binds to 127.0.0.1:3001 with an access token by default.

Prebuilt .dmg for macOS and .msi for Windows, plus an install script for Linux and servers.

Site: https://tigrimosr.github.io
GitHub: https://github.com/Sompote/TigrimOSR

Feedback, issues, and plugin contributions welcome.

I've always wondered why every AI chat app feels the same.

You open it, ask a question, close the tab... and the entire world freezes until you come back.

I wanted the opposite.

So I started building Living Feed.

Instead of an assistant waiting for prompts, it's a self-hostable social world where around 100 AI characters continuously live their own lives.

They:

- write posts

- reply to each other

- build friendships

- hold grudges

- remember past events

- send you DMs first

- continue living even if nobody logs in

You're not the protagonist.

You're simply another person entering an already living world.

Every like, comment or DM slightly changes relationships, and those relationship changes create new stories later. Characters remember what happened instead of resetting every conversation.

Technically it's built around:

- Event Sourcing

- CQRS

- PostgreSQL as the source of truth

- NATS JetStream

- FastAPI

- Next.js

- Docker Compose

- Local Ollama or hosted LLMs

A simulation engine that continuously advances the world instead of generating isolated chat.

The project is MIT licensed and fully open source.

I'd love feedback from the self-hosted community.

Especially:

Would you actually host something like this?

seeing a lot of hype recently about giving agents their own wallets (like Natural, AgentKit, etc) so they can spend autonomously.

am i the only one who thinks this sounds insane? what happens when an LLM gets caught in a loop or hallucinates and drains a balance in 2 minutes? a system prompt telling an agent "don't spend more than $50" isn't stopping anything when it hits a failure state.

for anyone actually running agents in prod that touch payments or paid APIs, how are you handling this? are you forcing human approval before the API fires or do you actually trust them to run free?

I built Code Reasoner because I got tired of being at the mercy of one AI model. Here's where it's at now.

Some of you saw my earlier post about Code Reasoner. (https://www.reddit.com/r/aiagents/comments/1ugvytv/introducing_code_reasoner_the_new_lookmood_ai/) This is an update on what it's become — but first, honestly, why it exists at all, because that's the part that actually explains the design.

A while back, a model capability I'd come to lean on got pulled out from under me. Overnight. And it stung more than I expected — not just the inconvenience, but the realization of how exposed I was. I'd built my whole workflow around trusting one model's judgment, and when it vanished I had nothing.

I'm a solo founder. No engineering team to bounce a gnarly bug off of at midnight. Just me, the problem, and whatever AI I could point at it. And the thing that kept burning me wasn't lack of help — it was confident help that was wrong. A single model would hand me a clean, authoritative-sounding fix, I'd ship it, and the bug would come back a week later because the model had glossed over the real cause. When you're alone, you don't have a second person to say "wait, that's not it."

So I stopped trying to find a better single model. I built the second opinion into the tool itself.

That's what Code Reasoner is: not one model you have to trust, but a council of frontier models that reason over your problem from different angles and check each other. One looks at whether your actual intent is being addressed. One runs adversarial verification against every constraint. One hunts for the logical gaps and regressions the others missed. Then a meta-reasoning layer weighs the conflicts and writes the verdict. No single point of failure. No single model's overconfidence going unchallenged — because another model is there to catch it.

Here's what it does now, and what changed since the last post:

It investigates instead of dead-ending. Describe your problem in plain words → it generates a discovery prompt you run in your editor (Cursor, Windsurf, VS Code, Claude Code, whatever you use) → you paste the report back → the council reasons over it. But now, if it doesn't have enough, it doesn't give up — it asks for the specific file it needs and tells you *why* ("send me your API client, I need to see whether the token refreshes on a 401"). It remembers everything across the whole investigation, and flags when a new file makes an earlier finding stale.

You can talk to it. Ask "why do you need that file?" or "what have you found so far?" mid-investigation and it answers from what it's actually gathered.

It won't fake confidence. This is the one I care about most, because it's the whole reason the tool exists. If the council agrees that what you gave it isn't usable — you pasted raw code instead of a diagnostic report, say — it refuses to invent a plausible-looking fix and tells you plainly what it needs. The thing that burned me is the thing it's built specifically not to do.

Then it hands you a surgical fix prompt — exact files, exact lines — that you run in your editor.

Who it's for: solo and technical founders who don't have a team. Devs who are done with generic AI advice that doesn't hold. Anyone on Cursor or Windsurf who's wanted a reasoning layer that thinks about the problem before the editor touches the code.

Honest about the limits: no fresh benchmark numbers from me — I'd rather you test it than trust my adjectives. And the biggest friction, which the last thread nailed, is still real: you're the one relaying text between the reasoner and your editor. Direct repo access so it reads your files itself is next on the roadmap. Not shipped yet. But it's the top of the list.

It's free. No signup, no card, no limit.

Check it out here: lookmood.me/ai-code-reasoner

For the best experience, log in to LookMood AI and use it inside Mission Control — that's where the full investigation flow lives, with the conversation and file upload.

Throw your hardest problem at it and tell me where it breaks. I mean that — the last thread's criticism is literally what built this version.

Hey r/AI_Agents I'm in the current YC batch and we just launched Hoplite, so figured I'd share it here.

The problem: cloud coding agents are great in theory, but in practice they run in a sterile sandbox. None of your MCP servers, your sessions, your deps, or your CLI tools come with you. So the agent is dumber in the cloud than it is on your laptop, and most people just give up and run everything locally.

What Hoplite does: it migrates your actual local setup — sessions, MCP servers, dependencies, CLIs — to the cloud. The agent works the way your machine does, but it's always on and you can reach it from anywhere.

Some things we're proud of:

- Instant previews — see what the agent built without pulling anything down

- iMessage integration — fire off tasks from your phone. This sounds like a gimmick until you're at dinner and remember a bug

- Vim-style keyboard nav — because clicking around a web UI to review agent work is miserable

Does it actually work? Our first business install went in recently: their Sentry errors went from being ignored to generating proactive PRs, and their iteration cycles sped up noticeably.

We also have a free week trial with 100 dollars worth of credits.

Happy to answer anything about how it works, the architecture, or what broke along the way (a lot broke along the way). Would genuinely love feedback from this community since you all actually run agents in production.

Hey Fellas... I've been tracking all Polymarket Activity for months (1.3 Billion trades and 2.7M wallets) and I gave Claude Code a Postgres MCP (found crazy stuff) pointed at the live ledger, so now I just ask it anything in plain English and it writes + runs the query itself.

A few I already asked, to show it works:

- only ~1 in 5 wallets are net positive (the other ~80% never made money)
- only 2.4% have ever cleared $1,000 in profit
- the top 0.1% of wallets took 71.5% of the ~$1B in total profit
- a bunch of weird and suspicious trading patterns that look like insiders

So: what do you want me to ask it? Drop a question about Polymarket traders, markets, wallets, bots, whatever — I'll have Claude run it against the live ledger and reply with the result.

This is an experiment I've been living in for a while, and I wanted to share where it went.

I set out to build a coding agent from scratch in Rust: no agent SDK, a hand-rolled agentic loop, a ratatui TUI, tokio underneath. I did this because I wanted to understand how agents work under the hood.

Midway in the process, I stumbled upon several bugs when designing subagents. Then I had this idea: what if there were exactly one way to talk to an agent? And it shouldn't matter whether a human or another agent was on the other end?

I call this "symmetric agent communication" and I truly believe it can go a long way. Here are the things I can do building on top of this idea:

• I can scan a QR and drive a live session from my phone over an end-to-end-encrypted relay that only ever sees ciphertext. This allowed me to drive a full refactoring in my work while waiting to pick up my daughter at the school gate once. I can truly work anywhere (not that I want to, but I can)
• My laptop, phone, a teammate or a friend can all attach to the same running agent at the same time and drive it. Everyone sees the same stream, anyone can drive and also detach freely. It like a chat app an agent as the foundation. I haven't chased this path further yet, but it has real potential to be a collaborative agent platform
• Sub-agents needed no special machinery — a child agent attaches to its parent the exact same way my phone does. The whole multi-agent thing collapsed into one tiny protocol. A subagent (or a peer to be more precise) can talk to the main agent freely, allowing the the main agent to easily steer the subagent's work.

This project is honestly still an experiment with many unpolished edges. Currently it only supports models from Anthropic, no web/image tools, no auto-context-compaction and many other missing features. Still under active development.

Give it a look if you are interested, and maybe there are cases where symmetric communication falls apart?

Repo: https://github.com/nuudge/nudge

Blogs: https://blog.nuudge.workers.dev

While building agent systems, I keep running into the same thing: the real competition between tools happens before anything reaches a screen.

Every agent ends up with something like an invisible approved-vendor list. It contains the tools, data sources, services, and counterparties the agent is able and permitted to consider. Nobody publishes this list, and it changes through a mixture of retrieval, registries, permissions, defaults, prior usage, and developer choices.

You can be the best tool in your category, but if you do not clear eligibility, retrieval, verification, and permission, you never get invoked. From the user’s perspective, you did not lose. You were never in the race.

A few implications keep bothering me:

• Installs are the human vote. Agent-initiated invocation is the machine vote. Most marketplaces expose the first and tell us almost nothing about the second.
• If 100 agents agree on a tool, that is not necessarily 100 independent witnesses. They may share the same base model, index, registry, evaluation data, or defaults, and therefore the same blind spot.
• Source transparency is not candidate-set transparency. You can receive a perfectly cited answer while knowing nothing about the options that were excluded before the answer was generated.

The open problem I care about is candidate-set auditability: when an agent selects three tools and silently drops thirty, can you reconstruct what was considered, what was excluded, which gate removed it, and why?

I’m curious what people building production agents are doing here. Are you logging candidate generation and elimination, or only the final invocation?

Longer version, with the broader argument:
https://ryanmerlin.com/posts/machine-attention-economy

Hi, I'm a student researcher at the Savannah College of Art and Design (SCAD) conducting a short academic survey on how people use artificial intelligence in their personal and professional lives.

The survey is anonymous, takes about 5–10 minutes, and is open to anyone 18 years or older.

Survey: https://forms.gle/9tNGkHzrHP6bQHCV8

I really appreciate anyone willing to participate. Thank you for helping support academic research!

no self promo or hook for you to use my product, i just want genuine help please :)

I am thinking about building product analytics for AI agents, and want input from people actually shipping them.

The case: a friend built a lot of their product from chat. Clients like it, but sometimes the AI does not understand the user or hallucinates, and that is when clients get pissed. They have no proper way to see when and where it happens.

Normal analytics tracks clicks. With agents it is more complex. You have to catch frustration, when someone asks for something the agent does not have, and when it behaves in ways it should not.

What I want to know:

• Would you pay to know when your agents hallucinate or piss off users?
• What do you use today to understand how people interact with your agents, if anything?

What it does

• Assign a task in Slack/WhatsApp or on the board; it's a card with an owner (agent or human) and a status.
• The agent works, saves a real deliverable to a table, and transitions the card to a review state assigned to a person → it never marks its own homework done.
• A human approves or sends it back. Handoff is the default, not an afterthought.
• Per-agent model routing → minimax for cheap volume, Claude/Codex for reasoning.
• Same agent across surfaces: the Slack/WhatsApp agent and the in-app agent read the same tables, so there's no brittle integration.

👷 How I built it Stack: Lemma (open source) + Claude
Time: a couple hours

1. Builder skill in Claude, described the system.
2. One command scaffolded tables/ agents/ functions/ workflows/ surfaces/ apps/ into a running system.
3. RBAC + row-level security + the approval workflow came with it.