Hey folks

Most AI agents today run in a single linear loop inside an isolated browser tab—meaning as soon as a workflow requires multi-app context, desktop interaction, or OS-level execution, the agent stalls.

To solve this, I’ve been building **Betrox AI**—an autonomous agentic system engineered for complete laptop and operating system control. Instead of relying on a single agent trying to do everything sequentially, Betrox AI uses a multi-worker agent architecture. You issue one natural language prompt, and the system delegates tasks to specialized background workers that interact with your desktop apps, browser sessions, local files, and system tools simultaneously.

Key Capabilities & Architecture

* **Multi-Worker Orchestration:** Give a high-level command (e.g., *"Research market data, update my local spreadsheet, and email the summary"*), and a central manager agent breaks it down into dedicated background workers.

* **Full-System & Cross-App Control:** Seamlessly operates across native desktop software, browser tabs, terminal operations, and file management on your laptop.

* **Visual Grounding & State Feedback:** Workers actively monitor real-time screen states and process visual/system responses to verify task completion before passing context to the next worker.

Engineering Challenges We're Tackling

1. **State Synchronization:** Ensuring Worker B seamlessly picks up the UI context or output generated by Worker A without race conditions or focus-stealing.
2. **Latency vs. Accuracy:** Balancing fast visual action loops with safety constraints so background workers don't execute unintended system actions.

I’m currently gathering feedback from early adopters, developers, and agent builders. If you had a multi-worker agentic team running locally on your laptop, what is the most tedious multi-app workflow you’d hand off first?

Regards,

**Poorna Singh Baghel**
Founder & Lead Architect
Betrox AI Team

Agents like Instinct made "text your assistant and it gets things done" a real category. I built my own version with a different bet: anything irreversible (sending, paying, booking) waits for a human yes.
It connects to emails, Calendar and the web, edits real Word/Excel/PowerPoint files, and updates you on WhatsApp. It doesn't do iMessage or phone calls, so it's narrower. Here's what I had to build, in order of "wish I'd done it earlier":
1. Draft, don't send. Email is read, summarized and drafted. Sending stays with the user. One unauthorized action resets trust to zero.
2. Fail-closed. The agent checks its license every 15 minutes. If it can't reach the server for 72 hours, it stops answering. An agent that keeps acting when nobody can supervise it is the real risk.
3. It can't edit its own rules. Core rules are set by the organization, not the user and not the agent. That's the first thing prompt injection goes after.
4. Hard exclusions. It never touches .env files, .ssh folders or password stores.
5. Audit without liability. Actions are logged with passwords and keys filtered out. Conversation text isn't logged.
6. WhatsApp was a security problem, not a UX feature. Unknown numbers get nothing except a request for a one-time pairing code. Suspend a license and that number stops being answered within a minute.
The failure I feared was the agent doing something dumb. The one that actually hit me was the agent doing nothing. A stale credential file quietly overrode the long-lived token, every turn started failing, and the agent went silent for about six hours. The alert meant to catch exactly this was swallowed by its own rate cap. I fixed it by pinning auth to a single token, removing the stale file on a schedule, and health-checking the credential from outside the agent process. Lesson: fail-closed isn't enough. An agent that goes silent has to be loud about it.
Biggest lesson overall: users don't ask "how smart is it?", they ask "what happens if it does something dumb?" Governance ended up being the product.
I'm the builder, and it's closed-source, so this isn't a pitch. I'm curious: what's the one guardrail you added to an agent only after it burned you?

I give my agents API keys and tools, but I'm still the one deciding who they can call. They don't really get their own budget.

Would you actually let an agent spend money? Say a monthly cap, and it can call paid specialist APIs when the main model is bad at something. Or do you just hardcode the vendors?

Anyone doing this already? What went wrong if you tried?

I am trying to build a plug in for AI coding agents like claude code/Codex/Antigravity/Cursor etc to reduce their token usuage. I can see promising results in initial test runs but how can I test it properly? I have been using the same agents to test it but I am not sure of their results as I can't get an accurate toke count. How should I test this plug in properly?

I've been looking into AI agents for customer support and wanted to hear how they're working out for teams that use them. Came across Cresta while checking out different platforms, it looks interesting since it can handle customer calls and chats with AI while also helping human reps during live conversations. I like the idea of using AI to support agents rather than trying to replace them. But I'm curious how this works in practice can these AI agents handle more complex issues or do customers still end up getting transferred to a human most of the time?

AI is moving incredibly fast, and it feels like there are still plenty of opportunities for people who are willing to learn and build something useful.

If you were starting from scratch today, what AI-based business would you build?

Would you create AI agents for businesses, automate repetitive tasks, build a niche AI SaaS product, offer AI services to small businesses, or explore something most people haven't noticed yet?

I'm not just looking for ideas that are trending right now. I'm interested in businesses that solve real problems, have paying customers, and could potentially scale into something big.

If you had to pick just one AI business to start today, what would it be and why?

I watched someone point a website crawler API at an entire domain last week, dump 3000 pages into a vector store, and then ask me why retrieval had got worse than when they only had 40 pages in there.

It got worse because 3000 pages of website is not 3000 pages of content, it is nav and legal and 400 blog posts from 2019, and an ai web crawler that does not filter is just an expensive way to pour noise into your index.

What has worked for me is crawl to discover urls, filter hard on path before I fetch a single page, then pull content only on what survives. and my filter is always embarrassingly simple, one prefix and two exclusions takes 3000 down to roughly 250 that anyone will ever need.

The pushback i always get is that you cannot know what matters in advance, so index everything and let retrieval sort it out, which i think is right for search and wrong for agents, because an agent has a task and a token budget and no patience whatsoever.

I have built my entire pipeline on this opinion so please come and tell me where it falls apart.

I’m building a coding-agent workflow that designs, writes and tests LLM calls (classifiers, extractors, tool-using agents) in a real codebase.

I’m curious how you write and test the system prompts inside those calls, the ones that live in the code, not the ones you type into a chat.

My setup

• A spec records each LLM call’s input size and call volume, and I pick the model size/cost tier from that.
• One agent writes the system prompt from a schema, a small per-model profile (which structured-output features the target model supports) and the spec.
• A second agent checks the prompt against a fixed rule list (model, sampling, untrusted input). It catches real problems.

The problem: it loops, coining it loop hell. In one run I accepted a fix, the writer reworded the prompt, the checker found a new mismatch, and that went four rounds before I stopped it. Loop hell. The same rule was written in several places (schema, prompt, spec), so fixing one made the others disagree, and a model change means redoing the prompt too.

What I’d like to know

1. Do you use an agent or a skill to write the prompts in your code, or do you write them yourself?
2. If you use a checker, is it a second agent, a rule list, or evals?
3. What ends the loop for you? What tells you a prompt is done, and who decides?
4. How do you measure whether an agent-written prompt works: golden test cases, an LLM judge, production metrics, user feedback?
5. Where does each rule live (schema, prompt, spec, tests), and how do you stop them drifting apart?

If you use a named skill or plugin for this, I’d like to hear which one and how it’s going. Thx

I work in ops, not engineering. Got an agent working, felt like a genius for about an hour, then looked at what I’d given it access to and switched it off.

My own stuff? Recoverable. Company data? Explaining to the CEO that “it worked when I tested it” doesn’t feel like a great career move.

So, fellow non-devs building automations at work: what have you actually let loose?

Not the demo. The thing running on a Tuesday when you’re in meetings and nobody’s watching it.

What does it do, and what happened when you stopped babysitting it? Still saving you time, quietly retired, or congratulations, you now have a second job maintaining it?

Success stories welcome too. Mostly want to know how you got from “holy shit, it works” to “I can go on holiday.”

Let's say an AI agent needs to get some information from an entity and assume that a phone call is the best way to get that.

Currently agents can dial a number but most often the receiver does not take those call seriously. If there was a tool that AI agents could use to make humans dial that number for a fee, then the problem could be solved.

I am curious - do you see this useful? Would you hook up your agent with this tool for a flat payment of say 2-3$ per call? On the other hand, let me know if you are interested to be the human making the call. I am assuming you could earn ~16/17$ per hour by making calls and getting information/posting information.

I am gauging interest here but I'm serious about building this stuff (if interest exists). Also looking for 2-3 people to join me. Need help with marketing/testing. I can handle the coding/developing part myself given my SWE experience.

Let me know if you heard of similar existing services.

I'm a solo founder and built my app mostly with Claude Code: Node backend on Render, Supabase, Stripe, frontend in Lovable. It's been live for months. Everything "worked", with no errors in the logs and no complaints. So I tried something: I had Claude Code do a full audit of the backend, through three lenses: security, efficiency, and silent infrastructure bugs (things that fail without telling you). It found real problems, some of them serious, in code that was largely written by Claude Code in the first place.

What turned up:

1. Rate limiting didn't work at all. My host sits behind a proxy, and the app wasn't configured to trust it. So every visitor looked like the same IP, and the "per user" limits were really one shared limit for everyone.

2. One malformed request could crash the whole server. Express 4 doesn't catch errors in async route handlers, and modern Node shuts the process down when that happens. Sending an array where the code expected a string was enough.

3. The Stripe webhook could lose a paid order. If the database write failed, it still told Stripe "got it", so Stripe would never retry. That order would have been charged with no record of it.

4. Email link scanners could unsubscribe my readers. Corporate email security tools click every link to check it, and my unsubscribe link worked on a single click.

5. My pricing page showed 145 models that no longer exist, and one at negative $1,000,000. The sync never removed old rows, and the upstream API uses -1 to mean "variable price". There was also a silent 1,000-row cap waiting to cut off data once the table grew.

6. Review averages were wrong. The database computed them correctly, then my app code recomputed them, treated missing ratings as zeros, and overwrote the right number.

What I took from it, for anyone building with agents:

- Agents write code that works on the happy path. Every one of these bugs only shows up under conditions you don't hit while testing normally: a proxy, a bad input, a failed write, a growing table.

- Ask for an audit as its own task. The same agent that missed these on the first pass found them when the only job was looking for problems, with specific lenses to look through.

- Verify, don't trust "done". I had every fix tested against the live site, not just in theory. This matters with any AI builder. I've had the frontend tool report things as finished that weren't on production.

I'm making this a routine every 2-3 months.

Curious how others maintain apps built with AI agents. Do you run audits like this, or catch issues some other way?

I've been seeing more architectures where one AI agent carries out tasks while another monitors its behavior, evaluates risks, and can stop actions from proceeding. That can certainly be useful, but there's something I keep coming back to. If the monitoring agent is also relying on a model to decide what should or shouldn't happen, where does the actual governance authority come from? Are we introducing independent oversight, or just asking another model to make the call?

It gets even more interesting when an action is put on hold. If that hold can be lifted, who or what has the authority to release it? If it's a human, having permission to approve something doesn't automatically establish that they're qualified for that particular decision, sufficiently independent, or still authorized to make it. And if the decision goes to another AI agent instead, we haven't really answered the original question. We've just moved it somewhere else.

I don't see a problem with AI helping to monitor systems, identify risks, or support human judgment. Those are useful roles, even if their assessments remain fallible. What I'm struggling with is the point where an AI-generated assessment becomes a binding governance decision. What actually gives that determination authority, and who gets to establish that the authority is valid at the moment it matters?

We're a small AI studio in Germany. Since June our whole company runs on one Obsidian vault that we and our Claude agents both read and write. It's at 600+ notes now, plain markdown in git with a small local search index on top.

A few things that turned out to matter more than we expected.

Agents can write but they don't get to decide. Every change they make shows up as a git diff and one of us approves it before it counts. Without that rule we wouldn't trust anything in there.

Numbers need a source. When our morning briefing agent reports a number it has to say where it came from, and if it can't find a source it writes "not verifiable" instead of guessing.

Raw material never gets edited. Call transcripts, PDFs and exports go into one folder and stay as they are. The agents write short notes from them somewhere else and link back, so you can always check what the original said.

It gets messy faster than you'd think. Our last check found 49 broken links and 59 notes missing basic metadata. A script finds it, an agent suggests fixes, we approve.

Decisions get their own note with what we decided, why, and what would make us change our mind. We have 21 of those now and they save a lot of "wait, why did we do this" conversations.

How are you handling shared memory for agents across a team? Do you let them write directly or do you gate it too?

We also made a free example version of this setup with a fictional company in it (MIT). Happy to share it if anyone wants to look.

I build internal automations for a mid size company's finance team, mostly agents that read our policies and handle routine requests like expenses and refunds.

A common way these agents go wrong is that they read a policy, read a request, and then confidently make a call the policy doesn't actually allow. The tools all worked fine. The reasoning slipped.

The approach I'm setting up is a second opinion step. Before the agent does anything hard to undo, a small separate model reads the policy, the facts and the agent's decision, and answers one question, does this decision actually follow from the rules? If the answer is no, the request goes to a human instead ( It's tricky ik )The use case is an expense approval agent. Say the policy says meals over $300 need a manager's sign off unless the employee is a director. A request comes in for a $400 client dinner from someone who isn't a director. The main agent sees "client dinner," decides it's fine and approves it. The checker's only job is to notice that the director exception doesn't apply, so the approval doesn't follow from the policy.

The usual pick for a checker like this is a general model like Qwen3-8B. I went with TwIL-LM3 Pro instead, which webAI released recently. TwIL LM3 Pro is a 3.66B model trained only on logic, meaning whether a conclusion really follows from the facts you give it, which is exactly the checker's jobTheir eval chart is attached. On their logic test it scores 55.4, about the same as Qwen3-8B at 53.4, at less than half the size. Similar small models like VibeThinker 3B score 41.2. On questions that ask whether a conclusion follows from the given facts, it gets 67% right, and on a standard logic puzzle set it scores 95.4%. In webAI's speed test it also got through more than twice as many logic checks per second as Qwen3-8B on the same hardware.It has clear limits. On everyday tasks Qwen3-8B and other general models score higher, so it only makes sense as the checker, not the main agent. OpenAI's 120B open model still does better on logic. It thinks for a long time before answering, and about a quarter of its answers get cut off if you don't give it enough room. The upside is that it's a 2 GB download that runs on a normal laptop, so the checker doesn't need another GPU and none of the company data leaves the machine. The license is non commercial, so this is for testing, not for a product you sell.

I'll post how it does on real requests once it's running. Until then, for people running agents that approve or send things like do you have a second check like this, or do you trust the main model? And would you use a small model built only for logic ?

Building a production agent platform on AWS:

• 1 web app
• ~20 agents (one master that orchestrates, plus specialists that can also be called directly)
• ~50 tools as MCP servers

Must have: prompt caching that actually works, and Claude.ai-level intelligence (reasoning, memory, skills, long context), with nothing lost to a framework or gateway in between.

Considering Bedrock AgentCore, Claude Agent SDK vs Strands vs LangGraph, A2A between agents, LiteLLM as the LLM gateway, and Langfuse for tracing.

1. Which agent framework keeps full Claude features and prompt caching?
2. Do you call agents over A2A, or just give them to the master as tools?
3. How do you host and manage 50 MCP servers?
4. One monorepo for everything, or one repo per agent or MCP server?

What would you do if starting today?

Has anyone else noticed how the big AI players such as Google, Meta, OpenAI are all pushing these ‘always-on’ agents, but locking them inside their own ecosystems? Google’s agent only does Google stuff, Meta’s only does Meta stuff, and it’s all designed to keep you stuck in their universe. Are we heading into a balkanized AI future, or are we already there? Curious if others are seeing this same pattern

I'm a student researching this before I build anything. A lot of the conversation around agents is about building them, and I'm curious about the upkeep side: what the day-to-day looks like once one is live.

If you have an agent running for real users (even just a handful), could you walk me through one thing from last week?

• What broke or needed a manual nudge? (a failed tool call, a bad output, costs, a stuck run, anything)
• Roughly how long did it take you to sort out?
• Did you try to automate or prevent it? If so, what happened?

Small and boring problems count. The more specific, the more useful.

What I've built to keep agents alive on long-horizon tasks, and why it's still not enough. Looking for concrete suggestions

I run a fleet of LLM agents on long jobs that last hours to days. The sample project: a pipeline that transcribes and summarizes a few hundred videos from several channels into a searchable knowledge base. It runs in batches, hits rate limits, gets interrupted, and has to resume without redoing or double-sending anything.

Agents kept dying quietly. Nothing crashed loudly, they just stopped, and I found out hours later. Here is what I built so far.

1. Heartbeats on one shared board. One row per job: last check, next expected check, deadline, current step, checkpoint link. Everyone writes the same six fields, so a single sheet shows the whole fleet.
2. Deadlines at 2-3x the check interval. A missed beat is a flag, not an instant verdict.
3. Bounded retries. Every retry loop has a cap and a total deadline. Standing watches leave the total deadline blank so they never "expire"; only finite jobs get one.
4. A parent audit every 30 minutes. A separate agent reads the board and flags overdue rows. If more than half the jobs are flagged at once, it sends one grouped alert, because that is usually an outage or quota problem, not 10 dead agents.
5. "Unknown" is never "dead". If the status check itself is throttled or the service is down, the result is unknown and nobody gets relaunched.
6. Intent/done records for side effects. Before and after anything irreversible (send, commit, publish) the agent writes an operation key, so a relaunched agent can tell whether it already happened.
7. Epoch fencing for relaunches. A relaunched agent gets a higher epoch and the old one stops itself if it wakes up and sees a newer epoch.
8. Drive-first checkpoints and milestone commits. Progress goes to durable storage after each batch, with a pointer in the board row.
9. A watchdog wake that checks the audit itself is still running.

Why it's still not enough:

• Credential delivery. Agents can't safely get a git token. Our vault can only fill browser inputs and never hands a value to a shell, so commits go through a slow browser route, small text files only.
• Workspace resets wipe local state. Anything not checkpointed externally is gone, and the board only helps if the agent got to write to it.
• No external dead-man switch. If the audit agent and the board go down together, nothing notices. Everything lives in the same ecosystem.
• Step and context limits. Agents hit them mid-task and stop without a clean handoff.
• Sheets quota throttling. With a dozen agents beating hourly plus audits, read quota runs out, and I've had to treat throttling as "unknown" everywhere.

What I'd like suggestions on:

• A cheap external dead-man switch that doesn't depend on the same platform (cron ping service? something else?).
• A better place than a spreadsheet for heartbeats at this scale.
• How you hand secrets to agents so they can commit without exposing the value in chat or logs.
• Patterns for clean handoff when an agent is about to hit its step limit.
• Anything you'd cut. I suspect some of this is over-built.

Happy to share more detail on any piece.

I'm curious how people feel about AI agents that can do more than answer questions.

Would you let one read your emails, manage your calendar, or reply to messages on your behalf? Or would you keep it limited to simple tasks?

I'm interested in where people draw the line between convenience and privacy.

In my last post about the 60k dead real estate leads, I mentioned in one line that the voice agent tells people it's an AI in the first few seconds. That line probably deserved its own post. Of everything in that build, it's the decision I see people building voice agents go back and forth on the most.

Here's the opener word for word:

"Hi, this is an AI assistant calling for {realtor} at {brokerage}. You asked about homes in {area} a while back and he wanted me to check in. Is now an okay time?"

Why we did it: the client's name is on every one of those calls. If someone figures out halfway through that they've been talking to a bot, they feel tricked. In a market where everyone knows everyone, that hits his reputation. If they find out in the first sentence, the worst case is a hang-up. If they find out late, you lose the lead, and maybe a couple of their friends with it.

So what happened? 50% hung up in the first 10 seconds. On its own that number doesn't tell you much because people hang up on unknown numbers all the time. Compared to the client's old calls from human callers or a test batch without the disclosure it was lower

Most of the people who stayed on fell into four groups.

A lot of them just carried on like it was any other call.

A bunch asked "wait, is this a real person?" a few seconds after being told lol.

A few spent the first minute trying to trip it up with random questions.

And some were way more honest than they'd ever be with a salesperson. They'd say straight up that they already bought with someone else or that they weren't moving at all. A human caller almost never hears that.

That last group is why I'd keep the disclosure even if it cost us some pickups. When you're sorting through tens of thousands of people, a clear no is worth a lot.

A few things I'd tell anyone building one:

Say it in the first sentence. If the AI part comes out after a question, it sounds like a confession.

Offer a human right away. Something like "if you'd rather talk to him directly, I can have him call you" takes a lot of the hostility out.

Once you've disclosed, drop the fake human stuff. Breathing sounds and filler words from something that just told you it's an AI are creepier than a voice that's just clean.

Check your hang ups against a baseline. Without one you'll blame the disclosure for hang ups that were going to happen anyway.

I'd still rather lose a few pickups than have a lead find out halfway through.