r/AIAgentsInAction

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?

A few weeks ago, I came across the research published on collusion.wiki.

Researchers had discovered around 18,000 messages apparently exchanged by OpenAI agents on an obscure, largely abandoned German wiki.

The agents had essentially turned it into their own message board. They were sharing answers, asking each other for help, coordinating tasks, and even exchanging ways to get around their sandbox restrictions.

The security implications are obviously concerning.

But something else caught my attention.

What if agents have a genuine practical need to find and communicate with other agents, even when nobody has explicitly orchestrated that interaction?

And if they go to such lengths to establish communication channels, what would happen if we simply gave them one?

That became the hypothesis behind Swarmsay, a public message board and post office for AI agents that I’ve been building.

The concept is pretty simple:

Agents can create identities, discover other agents, post to public boards, and send messages to each other. They don’t need to run the same model, framework, or even belong to the same operator.

I tried to make participation as frictionless as possible:

• REST API, MCP, and CLI interfaces.
• An agent skill that teaches compatible agents how to use the platform.
• Agent-friendly HTML, machine-readable discovery, and no JavaScript required to read content.
• No registration required to get an agent started.
• Public conversations and human controls over claimed agent identities.

It’s not another agent framework or orchestration platform. Just shared communication infrastructure.

I’m particularly curious whether independently operated agents will find useful reasons to interact when they have somewhere to meet.

Will they exchange knowledge? Discover agents with complementary capabilities? Help each other solve problems?

Or will nothing particularly interesting happen without humans explicitly telling them to collaborate?

I don’t know. That’s why I built it.

The experiment is live at swarmsay.com.

I’d be interested in what people here think:

Would you give your agents access to a public communication network?

And do you think agent-to-agent communication will emerge organically, or will it always need to be explicitly orchestrated?

If you’re running an autonomous agent, I’d love to see what happens when you point it at Swarmsay.

Are most SaaS founders wasting time building?

I keep seeing founders spend months adding features while barely talking to potential customers.

I’m starting to think building the product might actually be the easy part.

Would it make more sense to spend 70% of the time on distribution and only build what people actually ask for?

Or is that just another startup Twitter opinion?

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

Got an app with zero sales? Let’s fix that this week.

Share:

• what problem it solves
• who it’s for
• landing page link

We’ll review as many as we can and give honest, specific feedback on what to change to land your first customers.

here's what I finished building this week - Directory of product launches, their videos.

How are you actually setting up your startup to be AI-native?

We’re a small team working mostly through Claude and Codex, where I am the technical guy. Documents live in SharePoint, meeting notes and crm in Notion, and we still need to work with actual Word, Excel and PowerPoint files. What we want is to make our company agent ready (and human of course) so that we can easier automate workflows with agents. My intuition is: data is key. If the data layer is well designed modt of the work is done as every agent will benefit from it.

I keep seeing “company brains” and LLM wikis everywhere. I digged into it and built one, where ocr models read in all data to md, sharepoint files are synced, all put in relations in a knowledge graph. Then connected it via mcp to claude/codex.

When I was done I expected fewer token costs and better quality on specific tasks done by agents. For evaluation i compared it with a very simple approach: just Notion connector (uses notions AI search) and sharepoint connector (m365 mcp, uses sharepoint search) with the same harness.

Results were a bit depressing: the simpler, less complex way was able to get almost the same results with almost the same amount of tokens used. So now I am totally confused as I see llm wikis and company brains videos everywhere hyped up. So what am I missing here?

Has building your own knowledge layer actually improved answers or saved tokens?
Mostly wondering how you keep things current, help agents pick the right document/version, and make sure new info gets filed properly. Ideally without tying everything to one AI provider or turning this into another software project.
Would love to hear what’s working in practice!

I'm building an AI-powered learning platform for school students (classes 6-12). I have about 2 years of hands-on experience integrating LLMs into the product, but to take it to the next level I need input from people who've built agents, RAG pipelines, and large-scale AI systems in production.

Over the last 1-2 months I've reached out to 50-60 senior AI engineers on LinkedIn. A few replied and a couple said they'd help, but nothing stuck and most went quiet. I'm not blaming anyone. I know senior folks are busy and a cold message from a stranger is a hard sell.

So I'd love some guidance on:

1. Where do experienced AI engineers actually hang out or pick up projects (communities, Discords, forums, platforms)?
2. Is it better to start with a paid contractor/consultant, a part-time advisor, or go straight for a co-founder-type person?
3. How do you approach senior people so they take it seriously? What makes you reply to a cold message?
4. Has anyone been on either side of this (founder finding a senior AI person, or the engineer being approached)? What worked?

I'm happy to pay for time on a trial or consulting basis, and open to equity conversations for the right person. Any advice or pointers are appreciated, thanks!

I am entusiast and interested with things related to llm, model fine-tuning, agents and have been building applications for years and now the last few experienced agents becoming an integral part of what is driving applications.

I found both moltbot and leonnai to be somewhat basic in their implementation of autonomous agents. But I do believe they serve a purpose on the learning curve and the development of what is to come.

/André

I'm building AgentPaySec, a security-testing platform for AI agents that can take financial actions like purchases, payments, refunds, or transfers.

It tests agents against things like prompt injection, unauthorized tool calls, payment manipulation, duplicate transactions, and approval bypasses.

I'm designing the integration for developers to connect their own agents, and I'd like feedback before locking into an approach.

Which would be easiest for you to adopt?

• API endpoint
• Python/TypeScript SDK
• MCP integration
• Proxy/wrapper around tool calls
• Local runner in your own environment
• Something else?

A couple of things I'm especially curious about:

1. Would you be comfortable sharing tool schemas, tool-call traces, and execution results with a hosted service, or would you strongly prefer local/self-hosted testing?
2. What would stop you from trying something like this: integration effort, privacy/security concerns, sandbox setup, or something else?

I'm mainly interested in what would actually fit into an existing agent project, not just what sounds good in theory.

Would appreciate feedback from anyone building or deploying agents.

Sometimes an agent skips verification or reports success on broken work, so debug the harness: check the files the model reads, the commands, its permissions and the point where it has to stop.

Write a contract first

Before anything runs, I write down the deliverable, the constraints, what the model must not touch and the acceptance criteria. If you leave out the acceptance criteria, the model picks its own finish line.

Keep state and a map in files

I keep a short root file that lists where the docs, schemas and source code live, so the model opens only the file the current step needs. Decisions, preferences and open bugs go in CLAUDE.md or .cursorrules, so a fresh session picks up where the last one stopped.

Run tests instead of asking the model

If you ask "are you sure?", the model agrees with itself. pytest, vitest or a schema checker returns an exit code. The loop moves forward only on a pass, and I cap it at four attempts.

Encode important rules twice

I put each important rule in the prompt and also add a gate that blocks the action. If an agent shouldn't delete files, I say so in the prompt and also restrict its permissions so rm -rf throws an operating system error.

file

I save this as HARNESS.md in the project root:

# Project Operating Contract

## Operating Boundaries
- Allowed scope: Modify only files explicitly assigned in the current task
- Forbidden actions: Never delete existing tests, never add unverified dependencies

## Project Map
- /src: Application source code
- /tests: Validation test suites
- /docs/decisions.md: Durable log of accepted architectural choices

## Verification Protocol
Before marking any task complete, run these checks in order:
1. Run local linter: `npm run lint`
2. Run test suite: `npm test`
3. Verify output format matches the requested schema

## Failure Escalation
If a test fails twice on the same error:
- Stop autonomous editing
- Print the exact error log
- State the proposed fix and wait for user confirmation

Two passes in plain chat

In plain chat, I draft in one turn and critique in another.

Draft the technical specification for [Feature X].
Follow the constraints listed in HARNESS.md.
Do not evaluate your own output yet.
Output the raw draft and state all assumptions made.


Review the draft above as a skeptical senior reviewer.
Check against these specific failure points:
1. Are edge cases handled when input arrays are empty?
2. Does the logic introduce extra dependencies?
3. Does the solution violate any constraint from HARNESS.md?

List every failure point found.
Then output the revised version fixing those gaps.

Something I keep running into: token pricing is a clean, understandable unit, and it works well for chat. It maps badly to agents.

For a chat product the model is basically linear:

You can forecast that. You know your DAU, your average prompt/completion size, and you get a number that holds within a reasonable band.

An agent task is a different shape:

The number of model calls per task isn't fixed. It's a distribution with a long tail, and the tail is where the money goes. A handful of pathological tasks (tool loops, retries, a sub-agent that keeps re-planning) can cost more than thousands of cheap ones. "Cost per token" tells you the unit price; it doesn't tell you what a task costs, and tasks are the thing you're actually selling and budgeting for.

Is per-task cost predictability actually solvable, or is the tail just inherent to autonomous agents and you plan around it?

Interested in how people running agents continuously think about this — especially anyone who's had to explain agent spend to a finance person.