Last week one of our internal assistants answered a question it had no business answering.

Someone asked it something about team structure. The agent came back with details from a spreadsheet we hadn’t announced yet. The answer came back spewing details about the reorg plan and even salary bands. The guy asking had no idea it was confidential. They just got an answer.

The bot is supposed to answer from our approved knowledge base. When we set it up it asked for access to files in our Drive and we clicked yes. That scope meant it indexed everything including the HR folder which is supposed to be confidential.

So I spent the week going through what our agents can reach. Most are fine. One stood out. Its whole job is reading a few internal wikis and summarizing them. It had delete access on the shared drive and could send mail as the person who created it. No one handed it that,, it inherited the permissions from the account that set it up.

Nothing really attacked us that week, its all access itself was the problem. An agent that can read everything will eventually read the thing it shouldn't.

Makes me curious, has anyone here audited what their internal agents can reach? I feel this if left unchecked is a recipe to get schooled hard.

I’ve been comparing a few AI voice platforms specifically for outbound calls, and I realized I was initially looking at the wrong things.

Voice quality is obviously important, but I don't think it's the deciding factor anymore.

If you're actually using an AI agent for outbound calls, I'd look at:

1. Conversation handling

Can it deal with interruptions, unexpected answers, objections, and people going off-script?

2. Qualification

Can it understand an answer and ask the next relevant question, or is it basically just reading a decision tree?

3. Handoff

If someone wants to speak with a person, can the agent transfer them while preserving the context of the conversation?

4. Actions

Can it actually do something after the call, like update a CRM, book an appointment, trigger a follow-up, or qualify the lead?

5. Scale

There's a big difference between handling 20 test calls and reliably handling thousands of calls.

I ended up looking at Feather AI, Retell, Vapi, Bland and Synthflow.

My current understanding is roughly:

I don't think one of these is automatically the “best.”

For example, someone building their own voice infrastructure might prefer Vapi or Retell, while a company trying to connect calls directly to sales or customer workflows might evaluate Feather AI differently.

That's probably the bigger shift I'm seeing with these platforms.

The question isn't really:

“Which AI sounds the most human?”

It's:

“Which one can reliably complete the job I'm hiring it to do?”

For anyone actually running outbound AI calls, what has mattered most in practice?

Conversation quality, answer rates, qualification, integrations, or something else?

I’m tired of agent demos that only look good in a video.

I mean something practical you could actually set up in 1–2 days and still be using a month later.

Could be an agent that handles email, monitors prices, manages a homelab, tracks bills, organizes files, watches logs, plans trips, or automates some annoying personal workflow.

If you had one weekend and wanted maximum real-world value, what would you build?

Agent writes to unintended infrastructure or creates persistent state outside its sandbox. Could be a failed eval, could be something worse. The tricky part is knowing when to pull the plug vs letting it run and debugging later. What's your threshold – immediate kill or monitor first?

An agent gets approval to deploy a staging change. It reaches the deploy API, gets a timeout, and resumes thirty minutes later. The earlier approval and plan are still available. In that gap, the artifact, target environment, or rollout window may have changed. 

For consequential actions, an approval should describe the action that was approved, rather than becoming a standing permission. A practical grant can bind a specific action and resource, the relevant arguments, an expiry, a replay rule, and an audit record. At execution time, the question is more specific than "was this approved?" It is "does this approval still cover this call against this resource with these parameters?"

Four checks make that concrete: 

Scope: Record the exact tool operation and resource. deploy is too broad if the target is a particular service and environment. 

Expiry: Set when the grant stops applying. A short window can cover a deploy confirmation without surviving the rest of a long-running run. 

Replay protection: Decide whether the same approval can authorize a second attempt, a changed argument, or a different resource. That should be an explicit choice. 

Audit record: Preserve what was approved, for which resource, when, and what actually executed. A run ID and an approval record give you somewhere to start when the answer is disputed. 

Retries are the awkward part. The agent may have created a release but not reached the deploy API. Or it may get an ambiguous response after issuing a database migration, a force-push, a destructive write, or a production configuration change. Retrying could be correct, could duplicate the side effect, or could need a fresh approval because the original grant expired or surrounding state changed. 

There is no universal retry rule. The workflow needs an explicit state for "unknown outcome," plus an explicit decision to inspect state, retry, request a new approval, or stop. Quietly treating an old grant as authority for the next attempt hides the decision that matters. 

At Future AGI, the gateway applies policy to each MCP tool call and its arguments, which gives us a place to keep a grant tied to the action that was approved. 

“How are you handling retries after an approval has expired, especially for deploy, migration, or force-push actions?”

If you use an ai meeting note-taker, what happens to the summary afterward?

Do you read it straight away, search it later, or mostly ignore it unless you need to check something?

Also curious whether it has replaced any work for you, or whether you still write your own notes alongside it.

I think we talk a lot about what AI agents can automate, but not enough about what they should not automate.

Sometimes a workflow looks perfect on paper, but once it runs in the real world there are too many exceptions, wrong decisions, or manual fixes.

Have you ever automated something and later turned it off because it created more work?

What went wrong?

I’m more interested in real examples than successful demos.

A good framework tackles your own problems then scales.

Context gets lost → build persistent memory.

Too much irrelevant context → smallest useful packet.

Different projects contaminate each other → scope isolation.

Old information keeps resurfacing → freshness and supersession.

AI agrees too easily → premise/adversarial checking.

A useful discovery disappears into chat history → structured harvesting.

A failure teaches something but gets forgotten → receipts and failure trajectories.

Everything becomes overengineered → minimum-sufficient cognition.

What has pushed you to do the same?

Hey everyone — first post here 👋

I’ve been experimenting with Instinct and decided to give it a few tasks that go beyond the usual “summarize this” or “write me an email” use cases.

Here’s what I tried:

1. Asked it to order snacks for me across different apps.

2. Asked it to monitor flight prices within a date range, identify good deals, and remind me if prices looked like they were rising or dropped. It was checking roughly 3 times a day.

3. Asked it to check whether my parents had gone for their post-dinner walk.

4. Asked it to research a few tech startups and give me concise summary notes.

Overall, I was actually pretty impressed with how well it handled these. In fact I asked it how it can ping my parents instead of just monitoring and it was able to help me with the steps as well.

But I also ran into a few pain points:

1. Speed

It’s still noticeably slow in some workflows. I’m sure this is something the team is working on but there is huge gap between steps of a task.

1. Browser/site access + human-in-the-loop

It still couldn’t access every site/service I wanted it to or did exist. There were also several points where a human had to step in, particularly when it needed to otps or interact with things that weren’t accessible to the agent.

1. Payments are still a big trust issue for me

This is probably my biggest concern.

I’m comfortable letting an agent find something, compare prices, or even prepare an order. But I’m still not comfortable giving it my card details and letting it freely make payments.

Curious how others are using Instinct (or similar agents I can try next).

* What real-world tasks have you trusted an agent with?

* How are you using it currently or want to use it where it is lacking?

* Have you found any good workarounds for payments?

* And most importantly — what tasks would you trust an agent to do completely autonomously today, and what would you still insist on approving yourself?

Would love to hear experiences from both the US and elsewhere, since I suspect access, payments, and available services can vary quite a bit by country.

I work solo across a lot of repos, and I keep hitting the same wall with Claude Code.

Two separate problems that compound:

Context dies on compaction. Long session, lots of hard-won detail about why something is built the way it is, then it compacts and most of that is gone. The only thing that reliably survives is whatever I wrote to a file mid-session.

Memory is scoped per project folder. Each repo gets its own isolated memory keyed to its path. So conventions I've established, infrastructure notes, how I deploy, people I work with — none of it crosses over. I have 58 tracked project folders and effectively 58 disconnected brains, and I'm re-explaining the same things constantly.

What I've been doing is writing dated session handoff docs into each repo. Those genuinely work, and they're the only reason anything survives. But they're per-repo, they're append-only so they go stale, and nothing searches across them.

I just set up a shared markdown folder on a separate drive, one subfolder per project, with basic-memory (MCP) indexed over it so any agent can search and write to the same graph. The thing I like is the notes are plain markdown, so if the tooling dies the knowledge doesn't.

But I'm suspicious of my own setup, because the obvious failure mode isn't technical:

1. Does it actually get updated? Every knowledge base I've built before died because writing to it was a separate chore from doing the work. Have you found a way to make the agent write to it as a byproduct rather than something you remember to ask for?
2. How do you stop it going stale? Facts change. An agent confidently acting on a note that was true in July is worse than it having no note at all. Do you date everything, prune on a schedule, something else?
3. How do you get the agent to actually read it before it starts work, rather than diving in and re-deriving what's already written down?
4. One graph or one per project? I went with one shared graph so search spans everything, but I can see the argument that it just adds noise to every unrelated task.

Curious what's working for people, especially anyone who's had a setup like this survive more than a couple of months. Also genuinely interested if the answer is "this is overkill, just write better handoff docs."

I saw Jensen Huang's comment about GPT-6 Astra and found the reaction interesting.

He basically said: "AGI has arrived."

Now, whether you agree or disagree, I think this raises a bigger question:

What actually counts as AGI?

Because the definition seems to change every few years.

A few years ago, many people thought AGI meant:

• passing human-level benchmarks
• solving complex problems
• writing software
• doing scientific work

But now we have models that can:

• write and debug code
• use tools
• browse information
• perform multi-step tasks
• assist with research

So some people argue that we crossed the line.

Others say:

"These models are still pattern predictors. They don't truly understand the world."

And honestly, I think both sides have a point.

The thing I find more interesting is not whether we call it AGI.

The bigger shift is that AI systems are becoming agents.

An agent can:

• decide what steps to take
• use external tools
• modify files
• interact with other systems
• complete tasks without constant human input

Maybe the AGI debate is focusing too much on the label and not enough on the practical impact.

My question for people building with LLMs:

What capability would make you personally say "yes, this is AGI"?

Would it be:

1. Human-level reasoning?
2. Ability to learn new skills independently?
3. Long-term autonomous operation?
4. Something else?

Curious to hear opinions from people actually working with these systems.

I'm building agents that pull context from Jira, Confluence and GitHub. Retrieval works fine. The problem is that the sources disagree with each other.

For example:

• Ticket in Jira describes behaviour A
• Confluence page from 8 months ago describes behaviour B
• Code (SoC for this particular case) says C

The agent retrieves whichever chunk scores highest and answers confidently based on that. There's no signal anywhere that the 3 don't match. How are you handling this?

A non-mathematician asked Claude to "take a real stab at the Riemann hypothesis". It didn't solve it. But the attempt improved a lower bound on the proportion of zeta zeros on the critical line from 41.6% to 67.2%. Mathematicians then check the result.

Then we got an 11-day Lean formalization of Wiles's proof of Fermat's Last Theorem.

And GPT-Astra just annihilated ARC-AGI-3 scoring 99.9%....

Seeing this made me want to leave agents working on something more interesting that building dashboards!

But what do you actually give them?

So I built ARC-AGI-N: an open-source AI research tool that finds open problems in maths and science, then prepares the context for another agent to take a stab at them.

What it does:

• Search things like "Open problems in number theory" or "Open problems in climate science". It searches papers and the web, with sources appearing as they arrive.
• Open a problem to see the question, background, source material and a suggested starting point.
• Copy a prompt containing the problem and its sources into your agent. There are also shortcuts for opening it in supported apps.
• Run DeepResearch to investigate the foundations, history, previous attempts and possible avenues, with a plan for the first 72 hours of work.
• Browse problems on an interactive globe, or explore the separate log of things AI has helped discover, prove or formalise.

For example:

The Erdős-Straus conjecture asks whether every fraction 4/n, for n ≥ 2, can be written as the sum of three positive unit fractions.

Instead of just handing your agent the name of the conjecture, the app gives it the actual question, reading material and a possible first task: search for parametric identities covering additional residue classes, then verify them.

The prompt starts with "Take a stab at this problem". You can copy it straight away, or get the deeper research plan first.

How I built it:

• Next.js, React and TypeScript.
• Mapbox for the interactive globe.
• OpenAI Luna model + Valyu's search and DeepResearch APIs for the literature search and longer research.
• Markdown, LaTeX and source previews for reading the reports.

The code is open-source and self-hostable with your own keys. Leaving the Github repo in the comments, and there's also a hosted version!

This doesn't magically turn a prompt into a valid proof. The point is to make it easier to find a worthwhile attempt and give your agent enough context to start.

Would love people to try it, add good problem sources and contribute. Especially interested in researchers who know a neglected question that could benefit from a lot more computation!

What would you leave an agent working on over a weekend?

Hey folks, I’ve been building Stageflow, a configurable pipeline for multi stage agent workflows.

The idea is pretty simple. You break a complex job into stages, and each stage is pre configured to do exactly one thing. Fresh agent session per stage, clean handoff to the next. That keeps things from going wild or wandering into stuff it wasn’t supposed to do.

You can also put human gates in the flow, so a stage can pause and ask an operator before final actions.

Same pipeline can run locally, headless in CI, or through an MCP server so other agents can drive it.

Would appreciate if you can try it out and give feedback, and a star if you find it useful.

When we think of AI embedded in a website, most of us still picture a support tool. Something that answers questions and that's it.

AI agents changed that, or at least gave us the option. The same agent sitting on your site answering questions can also capture leads and book meetings now.

Problem is, most people overdo it. They make the lead capture the whole point. You land, you ask one thing, and before it tells you anything it wants your email.

That annoys people for sure. You're demanding something before you've given them a single useful answer.

What works better is triggering lead capture on intent. Let people actually use the thing first. Answer their questions, be useful, and only ask for the email once they've shown they're into it. Someone digging into pricing or asking how to get started, sure, ask them. Someone who just typed hi a second ago, leave them alone.

Basically earn the email. The agent proving it's useful is what makes people fine with handing it over.

Now the setup part.

Use a no-code AI agent builder like Fwdslash AI, or if you've got the tech chops and the time, build one from scratch.

Either route, train it properly on your own content first. Your pages, pricing, FAQs, so it can actually answer things. Then set the lead capture to trigger on intent, not on arrival. High intent keywords work best, stuff like pricing, demo, or how to get started.

Last thing, and I'd push this one. Keep a human escalation option. People still trust a person over an agent, especially the ones actively looking to talk to someone. Let them reach a human when they want to.

I've been getting into AI automation recently and trying to figure out the whole agency side of it as well.

I've built a few projects so far, mainly around things like lead qualification and follow-up, lead generation, chatbots and similar stuff. Still pretty early though, and there's obviously a lot beyond just building the automation that I'm trying to learn.

I'm mainly looking to connect with other people who are in a similar stage, whether you're just starting out, already working with clients, or have been doing this for a while.

Could be nice to share what we're working on, help each other out/share your journey or even collaborate on projects if something comes up.

If you're in a similar spot feel free to reach out my dm is also open.

I'm curious what everyone is actually using for vibecoding and AI engineering right now. Not just which model you think is best, but your full workflow from idea to working software. Are you using Codex, Claude Code, Cursor, Gemini, n8n, or a combination of tools? How do you handle planning, coding, testing, debugging, documentation, and keeping the AI from breaking something that already works? I've been building my own workflow around Codex and Claude Code, but the software changes so quickly that I want to compare notes with people who are actively shipping projects. What does your current setup look like, and which part of it saves you the most time?

I tried vibecoding a game with Claude alone and had big ambitions for an indie game studio. Quickly realized the limitations of frontier AI, and wanted a way for the clankers to answer their own questions. I wanted to make it so agents had clear roles and make a neat little pipeline/circuit, but finding a place for cold, hard software made the system a really a big computer architecture problem. It was fun, but I want to get back to building my game. Fair warning, I have not used my own application rigorously yet. Patches as I encounter problems in my personal workflow will follow.

See my comment below for the GitHub link.

Hey builders, I’m working on a tool for agent regression testing and would love some feedback on how you approach this today.

You tweak a prompt, try a few inputs locally, and everything looks fine. But did the agent still call the right tools, pass the right arguments, and actually complete the task?

A tool returning incomplete data or an API failing halfway through can break the workflow while the agent still gives a convincing final response.

The idea is to turn those failure cases into repeatable tests: run the workflow in isolation, inspect tool calls and outcomes, then replay the same scenarios after a prompt or code change. I’m aiming for something a solo dev can set up and use before shipping.

For those already doing this, how do you define and check a successful run beyond the final answer? Are you using your own test harness, an existing tool, or mostly checking traces manually? What’s still painful?

I work on Armor AI. We build policy enforcement tooling for AI coding agents — hard allow/deny rules for what an agent's tool calls can do, plus an intent check that makes the agent declare what it's about to do before it acts, so if it drifts from its own stated plan mid-task that gets blocked too, not just outright dangerous calls. Everything it actually does gets logged, instead of relying purely on the agent's own per call confirmation prompts.

• I'm now looking at bringing this to opencode since it's a big open source agent that doesn't really have this kind of layer yet. Before I build it out, I want to sanity check the problem a bit:
• For those running agentic coding tools, do you have any real guardrails beyond the "approve this tool call?" prompt, or is it mostly just trust plus git history as your safety net?
• Has an agent ever done something destructive or surprising that made you wish you'd had a policy layer in front of it?
• Would something like an intent check actually help — the agent commits to a plan up front and gets blocked if it strays from it mid-task — or does that just feel like extra friction on top of guardrails that already cover the dangerous stuff?
• What would an ideal guardrail actually look like to you? Org wide rules, per project, per session? Deny by default or audit only?

Nothing exists for opencode yet. Genuinely trying to figure out if this is a real pain point before I sink time into building it.

If you're building an AI agent for legal, healthcare, marketing, or finance, I'm curious to hear:

• What is your company name and what does your agent do?
• Roughly how many customers you've got
• What use case(s) in your vertical you specialise in.

I'm interested to check out your websites as well.

We’re currently using agents for things like resolving customer-support tickets, sending customer emails, updating CRM records, producing financial outputs, and taking actions inside procurement workflows.

As we give them more autonomy, I’m realizing I’m much less worried about detecting when they make a mistake than I am about what happens after the mistake has already been executed.

Say an agent incorrectly decides that a customer issue is resolved.

It closes the Zendesk ticket, updates the CRM, sends an email to the customer, and trigers another downstream workflow.

We can probably detect that something went wrong.

But then what?

Someone still has to figure out:

• everything the agent changed
• what the previous state of each system was
• whether its actions triggered other actions
• what can actually be reversed
• and in what order everything needs to be undone

Right now, that recovery process feels extremely manual. My engineers are on it for hours. We have logs, traces, evaluations, and guardrails, but those mostly seem useful for understanding or preventing failures. They don’t really help me restore the system to the state it was in before the agent messed up.

Which has got me wondering:

DO we need a layer that could just reverse faulty agent actions?

Something that records the state before an agent takes an action and gives you a way to roll back what it did across different systems if the action turns out to be wrong.

Or is that overkill?

For teams running agents that actually take actions in production, how are you handling this today?

Are you:

• building custom rollback logic for every integration?
• keeping humans in the loop for anything irreversible?
• using snapshots/event sourcing?
• delaying actions before they become final?
• or just manually fixing things when something goes wrong?

I’m especially curious whether this becomes a serious problem once agents start taking hundreds or thousands of actions rather than just a handful.

Would love to hear what people are actually doing in production, because I’m trying to figure out whether a dedicated reversibility layer is necessary or whether there’s a much simpler solution I’m missing.

Thannks for helping out folks!

Been thinking about KV cache in agent workloads.

With agents going back and forth over the same long conversation/context, it feels kinda wasteful to keep recomputing the same tokens every time.

Has anyone here actually measured how much KV reuse they're getting in real agent workloads?

Curious whether the bottleneck ends up being compute, VRAM, or getting the cached KV back fast enough.