The recent Workday lawsuit has sparked an important conversation about the role of AI hiring agents in recruitment.

AI can help recruiters screen applications faster, but organizations also need to ensure these systems are fair, transparent, and regularly monitored for unintended bias. Even when a human makes the final hiring decision, the recommendations made by an AI system can influence the outcome.

As AI hiring agents become more common, accountability and oversight will be just as important as automation.

What do you think? Should AI hiring agents only assist recruiters, or should they play a bigger role in hiring decisions?

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?

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

Standard-setting confers long-term commercial and intelligence advantages (equipment maintenance access, potential surveillance backdoors, chip dependency)

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.

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.

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!

xAI launched Grok 4.5 on July 16 for coding and agentic tasks, with Grok Build as the default coding/build experience. The release page reports results across DeepSWE 1.1, SWE Marathon, Terminal Bench 2.1, and SWE-Bench Pro, but the spread is a good reminder that benchmark numbers are harness-sensitive rather than a universal ranking.

For a real engineering evaluation, I would compare the same repository tasks with: - pass@1 and rerun success, not just one completion - time and tokens per accepted change - test/debug/tool-call traces, including where the agent asks for clarification - failures caused by context, permissions, or flaky environment state

The practical question for Grok Build is whether its long-running agent loop can leave a reviewable, reproducible trail, not whether a single leaderboard places it above another model.

Official release: https://x.ai/news/grok-4-5

Was reading about payment controls for AI agents and the part that feels risky is giving software access to a card it can keep using. Would it make more sense for an agent to request a single use virtual card for each purchase with a fixed amount, approved merchant and short expiry instead of holding permanent payment details? Curious whether people see transaction scoped cards as enough protection or if the bigger risk sits in how the agent interprets the users intent.

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.

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 made this short product demo for Curify using a classic Journey to the West animation.

The idea is to turn passive screen time into a more structured learning experience. Curify takes a video and automatically creates bilingual subtitles, vocabulary cards, character maps, and interactive exercises that children can use while watching.

Here’s the demo video. I’d really appreciate honest feedback:

• Does the concept feel genuinely useful?
• Is the workflow clear from the video?
• What would make parents or teachers more likely to use something like this?

You can also check out the website here:
https://www.curify-ai.com/

Any suggestions on the product, video, or website would be greatly appreciated!

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

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 am exploring a local reference design for agent workflows where a task does not become executable just because an agent proposed it or an orchestrator queued it.

The small pattern is: a bounded contract defines the intended slice, an admission check decides whether the current inputs match that slice, and a receipt records the result of a synthetic check. If the source, scope, or receipt linkage drifts, the run stops rather than silently broadening.

This is not a product announcement or a claim of a production control plane. The current work is local reference material, and any passing run is local evidence rather than independent validation.

For people building agent systems around MCP, where would you enforce the first hard "not allowed yet" decision: task intake, tool invocation, executor startup, or before a side effect? What information must that decision have in order to be useful without becoming an entire policy platform?

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?

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!

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?

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?

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

Сейчас скидка 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.

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.

Over the last few weeks, we noticed a pattern that made us rethink documentation.

Users rarely browse documentation anymore.

They don't open categories or navigate through menus.

Instead, they type questions exactly like they would ask a teammate.

"How do I integrate Slack?"

"Why isn't GitHub Sync working?"

"Where do I configure webhooks?"

The interesting part?

Almost every answer already existed somewhere in the documentation.

People weren't struggling because the documentation was missing. They were struggling because finding the right page took more effort than asking a question.

So instead of improving search again, we tried something different.

We built an AI Chat Agent that reads the documentation and answers questions in plain English. Every response is grounded in the published docs, so users don't have to jump between multiple pages looking for an answer.

Something unexpected happened after launching it.

The conversations themselves became more valuable than the answers.

We started seeing:

• The questions users ask most often.
• Documentation that people couldn't easily discover.
• Topics that needed better explanations.
• Features that created confusion during onboarding.

In other words, the AI assistant became a feedback loop for improving the documentation itself.

If you're curious, here's the project:
AI Chat Agent

I'm curious how others are approaching this.

Are you still relying on traditional documentation search, or have you experimented with an AI Chat Agent for knowledge retrieval?

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.