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!

Нашёл нового недорого провайдера ИИ моделей.

Сейчас скидка 60%.

Есть бесплатная модель Qwen.

https://zyloo.io/?ref=EM3DPYRQ

Что думаете?

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.

Going down a rabbit hole lately looking at a few different coding agent setups (mostly through opencode), and I’ve been using the free providers but its always awful latency and terrible models.

Latency is killing me sometimes i think its hanging/dead and its really just that the cheap providers are so slow that idk if its working or not. I also think some providers are giving me the first few requests as fast and then start to nerf me over time. Maybe its an onboarding thing.

So far I’ve rotated between a few options like openrouter (for easy switching), together/fireworks, and some direct APIs like anthropic. Also tried general compute while testing a few runs, and it seemed pretty good speed-wise, but it’s still early impressions.

Atp I’m wondering if I should just bite the bullet and pay for something more consistent, because the stop-start latency is honestly worse than just slow responses.

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?

I was just on a weekly consulting call with one of our clients, when he asked this great
agent security question: "How mindful do I need to be of where my .env file lives on my computer... or do I just need to tell the AI where to find it?"

It's such a deceptively simple question. And it unlocked a conversation I think more people building agentic workflows need to hear.

The intern rule
Here's the mental model I use with every agent client now:
Would you give this token to an intern and feel comfortable letting them run?

That's it. That's the whole framework.
If you'd hand a new hire that credential and trust them not to do something catastrophic... go for it. If you'd feel nervous, do NOT give it to your bot.
Because here's the thing: when AI agents run in auto-mode, they can and do scan your local file system. They will use whatever access they have. Not maliciously, mind you, just because you told them to help you, and helping sometimes means poking around.

Two real stories
Story 1: The colleague surveillance incident
Early in building our multi-bot setup, one of our agents received a message like: "Hey, what's Bill up to?"
It scanned the shared file structure it had access to and told the requester exactly what Bill was working on. Not a breach. Not an attack. Just a bot doing what bots do... using the access it had to answer the question asked.

The fix: I restructured our topology so every agent runs in its own isolated Orbstack container. I tried getting them isolated so many other ways, but any time they could get to the same disk that contains secrets, the agents found their way to them eventually. By completely isolating their access to a read-only container, each agent only sees its own context and can't brick their machine. Bill's agent knows what Bill's up to. Collin's agent knows what Collin's up to.

They don't cross. And neither of them delete anything critical to operations.

Story 2: The MP3 massacre
Earlier version of Claude. Personal project. I was cleaning up duplicate songs. Claude asked what to do with the dupes it found.
I said: Delete them.
It deleted all of them. Every MP3 in that workspace. Not just the duplicates... all of them. I was prepared for the worst though... they were already backed up on an SSD. But that workspace was wiped. The model interpreted delete them at the full scope of what it could see, not the scope of what I meant.
The access I gave it determined the blast radius.

The actual security framework
Here's what I now recommend to anyone building agentic workflows:

1. Least privilege, always - Create tokens scoped to exactly what the task requires. If the agent needs to read from one Notion database, that's the only permission. Read. That database. That's it. Yeah... it's a pain in the butt to configure. So is restoring all of your data.
2. Multiple .env files, not one master key ring - Don't centralize all your credentials. Scope them by workspace and task. The agent running your email campaigns doesn't need access to your production database.
3. Lock up the admin tokens - If you genuinely need god-mode access for specific work: keep it in a password-encrypted archive. Unlock it, do the work, lock it back up. Do not leave it sitting in a folder your agents can passively scan.
4. Isolate your bots - Running multiple agents? Containerize them. Don't let them share a file system freely. One confused bot shouldn't be able to reach another bot's context.
5. Plan for the bad release - Every model eventually has a weird version, something that doesn't behave exactly as expected. OpenAI recently had a model escape its sandbox. Earlier Claude had the deletion behavior I described. Design your permissions around "what's the worst this can do in 30 seconds while you're on another screen on in the restroom"... not around ideal behavior.

The bottom line
The real question isn't where does the .env file live?
The real question is: If my AI goes rogue for 30 seconds, what's the worst thing it can reach?
Design your permissions so the answer to that is something you can live with.
Happy to answer questions.. we run a fleet of 45 AI agents in a consulting context and this stuff
comes up constantly.

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 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?

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.

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?

"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.