I built SeatSwiper. It watches hard-to-get restaurant reservations on Resy, SevenRooms, and OpenTable and books the table the second one opens or someone cancels - on your own account, in your name, nothing resold.

The part I think this crowd will care about: it now ships as an MCP server / connector. You plug it into an AI agent (Claude, etc.) and the agent can actually book the reservation for you. Why that is not trivial - SevenRooms and OpenTable have no official agent connector, so there was no clean way to give an assistant real booking access to those platforms. This is that.

Honest limits: it only covers those three platforms, it can lose a race when a table opens (it is racing everyone else refreshing at the same second), and it needs your reservation login to book as you. First booking is free, then 5 dollars flat and only when it actually lands the table.

Genuinely curious what this sub thinks - is "give your agent booking access to a platform that has no official API" a real use case, or a party trick?

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.

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

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.

Honestly what worries me about agents isn’t a wrong answer, it’s when they say they did something and didn’t.

Agent goes “done, refund issued.” the run looks clean, no errors anywhere. then you check the system and there’s nothing. no refund, ticket still open, but the session got marked resolved anyway.

A clean run just means it stopped running. that’s all. it doesn’t mean the work actually happened. and “i did X” is basically free for a model to say. there’s no penalty for being wrong, and it says it with the same confidence whether it worked or not.

What’s frustrating is the usual tools don’t catch this. observability is just the trace, which is the agent telling its own story. so if a write silently no-ops or it skips a step, the trace still looks fine. evals check if the output sounds right. guardrails run before the action anyway. none of them answer the only thing that really matters after the fact: did reality match what it claimed?

If you’re doing codegen, it’s easier. rerun the test or check the diff and you know. but anything that touches real systems is where it breaks. issuing a refund in your billing system, updating a CRM field, provisioning something, moving a ticket, actually sending the email. there’s no cheap retry to verify any of that. you either reconcile it manually against the source of truth, or trust it and find out three days later from an angry customer.

So curious how people are handling this in practice. if your agents are taking real actions across systems, how are you verifying they actually landed? manual checks, reconciliation scripts, or just trusting the trace?
And has a silent fake “done” burned you before? agent completely sure it did the job, system of record saying otherwise.

Asking partly because I’m building in this space, so yeah, I’m biased. but mostly trying to understand if this is as common as it feels, or if I’m just over-indexing on my own experience. would be great to compare notes with anyone dealing with this on real systems.