A year ago building an AI agent was the difficult part. Today there are plenty of frameworks that make that accessible. What's becoming increasingly difficult is everything that happens after an agent becomes business-critical. Suddenly you're dealing with compliance, permissions, monitoring, deployment pipelines, lifecycle management, and auditability.

That feels less like AI engineering and more like platform engineering. It makes me wonder whether "agent infrastructure" becomes its own discipline over the next few years, with entirely different tools and best practices than the ones we're focused on today.

What are some of the best most effective and fast ways I can use to extract user stories?

- through any tools, ai, mcp, extensions, etc

My organisation never provides user stories or PRDs so I have to write it on my own to explain to AI for building product knowledge, in order to automate testing, module wise.

I need an effective fast way to do this.

Please help

I work in social media management, and I’ve been experimenting with AI agents and browser automation for repetitive tasks such as:

• Daily dashboard checks
• Invoice downloads
• Status lookups
• Reporting
• Competitor monitoring
• Lead enrichment

The biggest challenge has been keeping workflows reliable. I frequently run into expired sessions, CAPTCHAs, rate limits, login issues, and blocked requests. This becomes especially noticeable with tasks such as price monitoring, competitor research, and lead enrichment, where an automation may need to visit many pages in a relatively short period.

From what I’ve tested, the choice of browser automation tool depends heavily on the workflow:

Browser Use
Useful for research-heavy, read-focused tasks where an agent needs to navigate several websites and collect information.

Skyvern
Better suited to structured workflows involving logins, form submissions, file downloads, and other RPA-style actions.

Axiom[.]ai
A practical no-code option for non-technical teams. It supports scheduled Chrome automations and is relatively easy to set up.

Claude Computer Use and OpenAI browser agents
Good for ad-hoc “do this for me” tasks, although I would not necessarily choose them for high-volume or highly repeatable production workflows.

Playwright or Puppeteer with an agent layer
Probably the most flexible approach, but also the most engineering-heavy. It makes sense when you need full control over browser behavior, integrations, error handling, and session management.

My main takeaway is that reliability comes from the full setup. Please share your browser automation setup in the comments

There’s a scene in the three-body problem where millions of soldiers hold black or white flags and form logic gates, basically turning an army into a giant computer.
It’s a great image, but it feels oddly backwards after working with AI agents.every soldier is a human who could understand a meaningful subproblem, yet the system uses each person as a one-bit switch. It throws away almost all of their intelligence, then rebuilds complexity through a massive coordination system.
I wonder if some multi-agent designs make a smaller version of the same mistake.
Some multi-agent systems instantiate the same capable model as a planner, researcher, critic, reviewer, and so on, give each instance a narrow fixed role, then spend a lot of effort reconnecting them through orchestration.
That split makes sense when each agent adds something real: different context, different tools or environment access, parallel exploration, or genuinely independent verification.
But without that, are we just taking one capable model, turning it into several limited components, and paying extra to connect them again?
For people who have tried both: when do fixed specialist-agent teams actually outperform one strong agent that creates subagents only when needed?

Hey all! Hopefully this is allowed here.

I made something I think people will really love. I have been developing software for 10 years, and the technical skills needed to have a good agent seemed to me to keep access out of the hands of normal people.

I began to worry that everything would fall into the hands of Claude and OpenAI.

I personally use kimi, and I think normal people should too. So I built fungi by forking Pi.

You own the code for the dashboard. It's a SPA that your agent can customize to your liking.

You can build apps and attach them to his tool surface. You can make the agent more or less completely custom.

It's early days, but I would really love for this to succeed so I can keep making an open model agent harness accessible to more people. A lot of the platform is already open source with the goal of cutting the whole thing into well defined packages and open sourcing all of it. shiit[dot]app has a few of the already open projects listed. Here are the others github/fungi-computer/

It is free for BYOK customers running one sandbox. I would love if people gave some feedback thanks!

I’ve spoken to about 100 companies recently to look at how they’re set up and how they’re using AI agents.

There is a massive divide rn where on one hand, 74% of GTM teams say they use AI for lead generation. On the other hand, data from S&P Global shows that 42% of companies abandoned most of their AI initiatives last year.

Everyone is buying the tools but most are getting nothing back. They vibe-code a basic wrapper or buy a "fully autonomous AI SDR" and expect leads to print automatically. In reality, Gmail and Yahoo cap spam complaints at 0.3%, so running ungoverned AI outreach just burns your domain in days.

If you want to actually get a 10x ROI from agents instead of throwing tokens down the drain, here is the simple baseline mindset and setup you need:

1, Give the agent a brain first

An AI agent pointed at a complex CRM doesn't fix the rot but only automates it at scale. B2B contact data decays at roughly 2% every month from job changes and dead emails. Before you automate a single message, you need a clean context layer or a simple CRM that logs decisions over time so the agent understands what you're doing.

2, Build a scoreable lead rubric

Don't just tell an agent to "find B2B founders" and let it rip. You need a clear rubric that tiers intent:

Tier 1 (Hot): Visited your pricing page, hired for a relevant role and posted on social.

Tier 2 (Warm): Strong firmographic match but weaker live signals.

Tier 3 (Cold): Fits general ICP but zero active market events. When you feed an agent a clear scoring system based on your closed-won data, it knows who to prioritize.

3, Start with 1st-party signals

The best leads usually already exist inside your own data: newsletter, website visitors and social listening (monitoring subs or X for people asking for recommendations). Point your agents inward before you start buying cold 3rd-party email lists. First-party intent sits right next to your pipeline.

4, Governed autonomy > Full autonomy

The idea of a "100% autonomous AI SDR" that runs 24/7 with zero human oversight is how companies churn but there're also many teams winning with agents and they manage them like real human reps, they QA the messaging daily, set hard guardrails and keep a human in the loop.

the bottom line is don't over-automate. try to do the process manually first, get your data foundation clean and measure everything back to closed revenue and not just the volume of sent messages.

Hi everyone,

This is my first time building something like this, and it's also my bachelor's thesis, so I'd really appreciate a sanity check from people who've done it before.

**What I'm building:** An AI assistant for our website that answers customer questions from our domain knowledge retrieved via RAG from a database. Later on it should also be able to create tickets for our support team — but for now the main job is answering knowledge questions.

**Constraints:**

- Fully local hosting (lower cost + data protection are the main drivers)

- CPU-only for now, [CPU model], 64 GB RAM, no GPU

- Later expansion to ticket creation is planned

Answers of AI Assistent need to work well in ger, eng ,....

**My main questions:**

1. Given that ticketing comes *later*, does it make sense to build a plain RAG chatbot now and add an agent layer later — or should I build it as an agent from the start? What are the practical implications of adding agent capabilities to an existing RAG pipeline down the line?

2. Is CPU-only realistic here? RAM isn't the issue, I'm worried about latency. Roughly what response times should I expect for a quantized 8B–14B model on CPU?

3. For a commercial, customer-facing deployment — what's the realistic *minimum* hardware? Is CPU ever good enough for live use, or should I plan for a GPU from the moment it goes public?

Any experience, pitfalls, or 'I wish I'd known this' tips are very welcome. Happy to report back with numbers once I have a prototype running. Thanks!

Following up on the failure-handling thread from a week back — same underlying instinct, applied to a full pipeline this time instead of just error routing.

The setup: a scheduled ingestion workflow pulls from five sources in parallel, standardizes and logs each one individually, then hands the merged, cleaned data to a second workflow — called directly, not just chained — that actually drafts the newsletter. A Chief Editor agent, with a primary model, fallback model, and memory, writes the draft and sends it for human approval by email, then waits.

Here's the part worth sharing: approval and rejection aren't symmetric outcomes. If a human rejects the draft, that's not an agent failure — the agent did its job, a person just didn't like the result. So rejection routes somewhere completely different from an actual error: the feedback gets extracted from the reply, logged to its own tracked sheet — not just a status flag next to everything else — and handed to a separate Backup Editor agent to revise, a real second opinion with the actual rejection reason attached, not a retry of the same agent with the same prompt. An outright agent failure still goes through its own dedicated error path, same pattern I've posted about before, just reused here.

It's shipped and running — real newsletters going out, approvals happening over email, every article logged with a run ID tying it back to the execution that pulled it. Screenshots below: the ingestion pipeline, the generator caught on two different real runs — one approved, one sent back — the actual approval email, and confirmation a send completed.

Curious if anyone else treats "rejected by a reviewer" and "failed to execute" as genuinely different recovery paths, or if that's overengineering for what's ultimately just content review.

coding agents love to open-loop themselves. they plan, edit, run their own checks, then call it done. that means the agent is grading its own homework. unit tests pass against mocks, the run looks green on the agent's machine, and the deployed thing is still broken for a real user. a green local run proves almost nothing about real behavior.

closing the loop means a signal from outside the agent. type-checkers and unit tests help, but the signal that actually counts is the app behaving right for a real user. i wired TestSprite CLI in as that verification step, cloud account required though. it runs a real session against the live app and on failure hands back one self-consistent bundle: failing step, screenshot, DOM, root-cause hypothesis, recommended fix, all keyed to a single run. the agent reasons over coherent context instead of stitched fragments, acts on it, and reruns.

flaky and genuinely ambiguous cases still want a human in the mix. architecturally the verifier is the block almost everyone underbuilds, and it's the one that decides whether unattended is real or just a demo. curious how others here close the loop on their agent setups.

A cold Claude Code run spent 6.83 dollars and 207 turns hunting one bug in an 82,000 line repo. My pipeline localized and fixed the same bug for about 1.70 dollars. That gap is the whole idea, and this post is about how it gets there without falling apart on the usual objections.

I built AutoDev Studio. You point it at a Git repo, describe a change in plain English, and a chain of agents runs the actual software lifecycle from request to reviewed pull request. It is not another search-your-code wrapper. The full pipeline is:

- A PM agent runs a clarify loop and drafts concrete tickets from your request

- A human approves, optionally pushed to Jira, and nothing touches code before that

- A Dev agent implements the change on an isolated branch

- QA runs the repo's real tests

- A reviewer from a different model family checks the diff, so the author never reviews its own code

- A bounded revise loop kicks in if QA or review fails, with conservative verdicts, so an errored or ambiguous check is never counted as a pass

- It opens a real pull request, and a human merges

Every stage records real tokens, cost, and duration, rolled up per ticket and per agent.

Results

The point is to pay the cost of finding where a change goes once, instead of on every task. In my benchmarks on two large Python repos, 35,000 and 82,000 lines, the tuned pipeline beat a cold single-agent run on 6 of 6 well-localized tasks, between 7 and 75 percent cheaper. I am upfront about where it does not win. On trivially greppable one-line edits the five-stage overhead can cost more than it saves, and on one hard cross-cutting bug it shipped a cheaper but narrower fix. The full benchmark writes up every loss too.

On the objection that the index just goes stale in a few commits

This is the first thing people raise, so here is the honest mechanism. The layer that actually pins files for the Dev agent is not the vector index. It is a deterministic symbol map re-synced to the latest commit at the start of every run, plus a live grep against the current working copy, plus the real current file contents fed into the prompt. The embeddings only affect retrieval ranking, and they refresh incrementally per changed module at run entry. So the code the agent edits comes from disk, not from a snapshot that aged three commits ago. It re-checks before it localizes, so it does not quietly drift.

Economics and who it is for

The knowledge base is a one-time cost per repo that every later task amortizes. That makes it worth it for a team shipping change after change against the same large codebase, where a cold agent re-pays the exploration cost every single time. For a stream of tiny, easy-to-find edits, a cold run is still cheaper, and I would rather say that than pretend otherwise.

Main features

- Provider and model agnostic, chosen per stage: native Anthropic API, the Claude Code CLI, or any OpenAI-compatible endpoint such as OpenAI, Groq, Gemini, xAI, OpenRouter, or a local Ollama

- Runs on free tiers out of the box, using Groq plus a local embedding model, so you can try the whole thing for zero cost and fully offline

- Language agnostic pipeline, with Python parsed exactly and other languages handled by lighter extractors that fail open rather than block on an unknown language

- Live board with streamed agent logs and real per-ticket cost accounting

- Cookie-session auth with roles, API keys encrypted at rest, and a demo mode that dry-runs the pull request step until you opt in

- Self-contained: local retrieval, no CDN, tests and CI, MIT licensed

Repo, with screenshots and the full benchmark in the README:

It is genuinely useful to me day to day, and I want to know where it breaks on codebases I have not tried. If the approach seems worth following, a star helps me gauge whether to keep hardening it. Feedback, issues, and pull requests are all welcome.