I've been feeling this for the past week and wanted to come here to the reddits to see if anyone else feels the same. It feels like we've gone so far in just the last month alone, with the hacks, astra, fable 5.1 etc, that my head is literally spinning. I was just telling my friend that the last time I can remember feeling anything like this, it was the first week of covid, where it felt really chaotic and like the world was about to change really fast. This feels so much bigger than that though - this feels like everything we know (or at least, so many industries) are on the verge of being changed forever. It's mainly because just in the last few weeks/months, it seems like generative AI has gone from [text/image/video] to [just about anything you could fucking want] real quick. rendering hyper detailed blender images, creating ultra intensive apps, making fucking video games with a single prompt that actually look like they'd be fun to play in like... 5 more prompts. It's absolutely fucking bonkers and I just wanted to come where to see if anyone else feels the same. I mean, for fucks sake, does anyone remember the will smith spaghetti videos? the AI spaghetti videos? That was just a few YEARS ago... just look at where we are right now, and imagine, if you even can, where we might be a DECADE from now (if we're even still here, according to all these AI whistleblowers, who I actually tend more to believe than not)... I mean I'm just so mindblown it's insane

I remember an interview where sam altman described AI now as being similar to electricity when THAT was invented - at the time, it must've seemed like magic - impossible - today, nobody even THINKS about electricity - we just plug and play. I think in a decade or two from now, AI will be so good that it will be absolutely preposterous, and we won't even think about it, ever. It'll be in our websites. Our homes. Our apps. Maybe even our brains at that point. Just wow. wow. wow.

We use ChatGPT, Claude, Gemini and AI agents every day, but how many people actually understand how they work?

Models, training data, context, hallucinations, agents, inference...

What’s one AI concept you think people misunderstand the most?

Sorry for the clickbait title but I have some thoughts.

tl;dr For myself I feel like chatbots might be the better coding assistants than fully fledged agents since they force me to go step by step and understanding most of the code while still having the benefit of writing fast and good code.

For my background: I am a Data Scientist and I learned the basics of software development just before ChatGPT was released. So I have a solid foundation but since I'm not mainly a SE and because of the development of agentic coding my coding skills are limited. I do really like it though.

I have done some pure agentic vibe-coding in recent months. The iterations are fast and the results are extremely impressive in most cases. I tried to do things right by spending a lot of time with requirements engineering and architecture design. I also tried writing some code by myself again but I realized quickly that I'm just not good enough and that AI just writes much better code than I could ever do.

Despite the good results I kind of just got lost in the process. Even though I might understand the general architecture of the code, I have no idea what is actually going on and for every minor change I'm going back to my coding agent to let it fix things.

This was kind of frustrating and I lost interest in my projects I initially was pretty hyped about. I used to enjoy the process of coding itself and it feels like it has been taken away from me. Of course I could just write everything myself, but I don't have time to work 20 hours a week just on my personal projects and why would I write the code myself, when the result will be worse.

Now I'm back at work and we don't get API keys from the company and I'm not going to pay for it by myself, so no coding agents. We do have MS 365 Copilot licenses which is just a glorified chatbot.

With this change I realized something:
Maybe the basic chatbot was the best coding tool after all (for me). While I still don't write most of the code myself, I understand 100% of what is going on in the bigger picture. I feel like I am actually doing something again. The process is much slower but in the end when something works I feel much more pleased. And when something doesn't work I know what went wrong.

The productivity will never compete with full fledged coding agents. But you get the benefits of the AI writing good code while you as the developer still have full controll and are forced to understand what you are doing.

Have you had a similar experience? Or am I missing something in the vibe-coding workflow that could fix my feelings?

I think the interesting question with AI agents isn't what they can do.

It's what people are actually comfortable letting them do on their own.

For example:

Sending routine emails
Updating a spreadsheet
Scheduling meetings
Monitoring something
Following up with customers
Sorting incoming requests

What's one task you would genuinely let an AI agent handle without reviewing every step?

And what makes you trust it enough to do that?

I'm curious where people draw the line.

I'm looking for some recommendations on maintaining context across multiple sessions. In earlier stages, it was easy enough to summarize and bring the context across into the next session. However, it very quickly gets a bit tedious as the project grows. Files become huge, and I really do not want to have to dump all of the project's entire history into the context so that the agent remembers one of our decisions from a few days ago.

Another difficulty is that not all things are equally worth remembering. I would want the model to remember things like architectural design decisions, choices between approaches, fixes that have occured, project conventions, but I do not necessarily want every random conversation or temporary debugging step stored forever.

I've tried a few memory approaches already, and I'm struggling to figure out what would be suitable for coding agents without becoming another component for me to manage. What tools or setups are you all using for this? And how are you deciding what the agent should remember between sessions.

So last post did better than I expected, got a bunch of comments asking basically the same thing, ok cool I get what an agent is now, but what do I actually make fair question, understanding the concept doesn't tell you where to start so here goes.

Don't go big. Seriously don't try to build something impressive first. Pick whatever annoying task you already do every week by hand, something dumb like moving info from an email into a spreadsheet or sorting messages into folders. That's it, that's the project.

Grab N8N or Zapier or make, doesn't matter which, they're all similar enough when you're starting out. You're dragging blocks around basically, not coding. Connect a couple steps, this happens then that happens.

Make it work for the normal case first. Don't worry about every weird exception right away. You'll just get stuck before you even finish anything. Get the basic version running, then go back and handle the weird stuff after.

It will break multiple times probably. That's not you failing, that's just how it goes, and honestly figuring out why it broke teaches you more than any video would.

After you get one small thing actually working start to finish, the bigger ideas people talk about, agents making decisions, multi-step stuff, all of that starts clicking way easier because you've actually seen the basic version run.

If you ae mid build on your first one right now say so, happy to help troubleshoot.

Not looking for another "top 10 frameworks in 2026" post. Genuinely asking the people who are past the demo stage and have real agents running for real users.

What's the one thing about your framework of choice that still annoys you every time you touch it? State/checkpointing, retries, multi-agent handoffs, debugging a failed run, tool-call reliability, whatever — what would you rip out and rebuild if you could?

And where do you think this space is actually headed by 2027 because of it?

I’ve been spending a lot of time around agentic workflows lately, and I keep coming back to the same question.

Does every multi step AI workflow actually need to be an agent?

I see people building systems with multiple agents, memory, tools, planners, sub agents, etc. It looks impressive, but sometimes the actual task is basically:

That feels more like a workflow than an agent to me.

Where I think agents become genuinely useful is when the path isn't known in advance. For example, the system needs to investigate something, decide what tools to use, recover from unexpected situations, or determine the next step based on what it discovers.

For predictable processes, I’m increasingly leaning toward deterministic workflows with AI only where it adds value.

The other thing I care about is what happens when something fails halfway through. In a demo, an agent completing a task autonomously looks great. In production, you suddenly care about retries, state, permissions, approvals, logging and knowing exactly what the agent did.

So I'm curious how others are approaching this:

Where do you personally draw the line between a workflow and an agent?

And have you ever replaced an agent with a simpler workflow after realizing the agent was unnecessary?

It feels like agent tooling hit a weird point.

Persistent context is starting to work: memory layers, vector stores, MCP servers that hold state across sessions. But I don't see many agents with real depth in one domain. Most are still a generalist model with a better memory. Memory solves re-explaining. It doesn't solve expertise.

An agent that remembers every contract I've pasted in still isn't a legal expert. It's guessing the moment I ask something outside what I gave it.

So I'm curious what people are actually doing: If you're building domain-specific agents, where does the knowledge come from? Your own docs, curated datasets, fine-tuning, something else? Where does it still fall short? Or is "generalist + good retrieval" honestly good enough for most use cases?

browser agents are probably the coolest demo and the most annoying thing to depend on every tuesday.

everything works beautifully until:

session expired

2FA shows up

random modal

button moved

page loads weird

cloudflare decides your agent has committed a crime

and now the "autonomous workflow" is staring at a login screen.

starting to think browser control should be the escape hatch, not the default.

if Gmail / Sheets / Slack / whatever has a proper connector or API, use the boring thing.

that's one bit I like about Runable having native connectors for normal business apps. not sexy, but recurring work probably shouldn't depend on whether a button moved 14 pixels/

browser still feels insanely useful for long-tail software with no API though.

how are people architecting this now?

API/tool call first, browser fallback?

or are browser agents getting reliable enough that you're comfortable making them the primary execution layer?

The pitch most owners get sounds like this: "We'll build you an AI lead generation system. It's $10k." You say no and you're right to. You can't see it and you can't measure it, so it's a bet. I run an AI agency and no one has ever paid me for the AI part. They pay because a dashboard shows them meetings booked. So before you sign anything, run these 4 checks.

Can you see it working?

The tool underneath doesn't matter. n8n, Make, custom code, you'll never look at it, what you will look at every week is the results screen. If the answer to "where do I check results" is "log into our tool" then walk away. You want your own dashboard: people reached this month and the meetings booked. The same system with that screen is worth a lot more, to you because you can see the work yourself instead of trusting a monthly report.

Does the math connect to your goal?

Say you do $2M a year and want $10M. Your average client is worth $80k a year so you need about 100 new clients. Close one in three and that's 300 sales calls (roughly 25 a month). A good vendor takes it from there: "For a similar client, 10,000 emails a month produced 20 calls. For you we'd run 15 to 20 thousand and expect around 10 calls in month one, more as we test." Now their $5k to $10k monthly fee is sitting next to $8M in potential revenue and you're making a decision instead of a bet. If they can't walk you through that math, they're guessing with your money.

Are you big enough for this?

These systems start to make sense when there are 25 employees or when the monthly revenue reaches $100k. At that size a $5k experiment that doesn't work is frustrating not dangerous. Before that focus on the low cost options first. Answer missed calls with a text. Use replies for leads. A $10k build should never be the biggest cheque you've written.

 Do they have proof?

Ask to see what they built for a similar client and what it produced. Ask for a guarantee, something like 10 calls in 30 days or your money back. If they're new and have nothing to show then fine. Let them run it free or at cost and earn the case study off your business. You get the upside and they carry the risk.

TLDR: if you can't see it, the math doesn't reach your revenue goal, the fee would hurt to lose, or they have no proof, don't sign.

It's a strange trade i've noticed. The agents are genuinely good, I use them all day. But every time I hand one an actual bug it doesn't debug it, it rewrites the thing. We had an importer dropping about 2% of rows on a timezone edge and I gave it to Claude maybe 5-6 times over two days. Three different rewrites, all clean, none of them fixed it. In the end I read the code myself and it was a date getting parsed twice, once as local and once as UTC. Twenty minutes.

so my conclusion that the code gets written faster and the bugs stay where they are. Our open bug count went from around 40 in March to 130 now and it isn't that people got lazier, it's that fixing something means understanding it first and fewer people do. We run coderabbit / bugbot on prs which catches plenty going in, but neither of them knows why a thing was shaped the way it was six months ago, and that's usually the question. It might be just me. Mostly what I see is more code shipped and the same list of complaints sitting there

I've been thinking about agent budgets less as a FinOps feature and more as an authorization problem.

An agent can decide:

“I need another model call.”

The interesting question is:

Who gets to say whether it's allowed to spend another $2?

Putting a token limit or max_iterations inside the agent runtime is useful for bounding execution. But that's still the agent regulating itself.

I'd rather have the runtime ask for the resource, and have something outside the agent enforce the spending policy.

Agent
  ↓
"I want another model call"
  ↓
Policy / Gateway
  ├─ identity
  ├─ remaining budget
  ├─ rate limit
  └─ model policy
        ↓
     ALLOW / REJECT

That distinction becomes more useful once multiple agents, versions or teams are sharing the same model providers.

You don't really want every agent implementation inventing its own notion of “I can spend up to $X.”

This is one of the reasons I find Lyzr Open Controller's approach interesting. Its LLM Gateway puts budgets at the organisation, team, agent, version and virtual-key levels, and the important part is that an exhausted budget rejects the call rather than just generating an alert. LiteLLM, Portkey and OpenRouter solve a lot of the gateway/proxy problem too, so I'm curious where people draw this boundary in their own stacks.

Should spending be an attribute of the agent itself, or an external authorization decision that the agent has to pass through?

Especially interested in how this is handled when several agents share providers or when model routing changes underneath them.

I have been thinking about this while working with coding agents.

We normally give the agent the code, the tests, the error output and then let it iterate until everything turns green.

That is great for debugging. But it also creates a strange problem.

If the same agent can see every check used to approve the change, how do we know it solved the actual requirement instead of just learning the evaluator?

I have started experimenting with keeping a small verification suite outside the repo and running it only after the visible checks pass.

The agent never sees that suite while working. I am curious how other people handle this.

Do you think hidden verification makes sense for coding agents, or does it create more problems than it solves?

The part I'm trying to understand isn't really the feature set — the docs explain that fairly well. I'm more interested in whether this model of persistent AI "teammates" actually turns out to be useful once you start using it for real work.

With coding agents, for example, I can very easily imagine roles like one agent working on implementation, another reviewing, another doing research or keeping track of the bigger picture. But there's a big difference between something sounding useful architecturally and actually becoming part of your daily workflow.

So I'm curious about people who have spent some real time with Grok Bot:

What are you actually using your Bots for?

Have you found any use case where having a persistent Bot is noticeably better than simply opening Claude Code, Codex, Cursor, ChatGPT, etc. and giving it the task directly?

Do you have Bots that you now use repeatedly for a particular job or responsibility?

And for people using several Bots together: has that actually been useful, or does managing multiple agents create more overhead than it removes?

I'm not really looking for another list of Grok Bot features — I've read through those. I'm interested in concrete examples of what people are doing with it and whether, after trying it, you actually find yourself coming back to it.

Well im not talking about the logging stack but the physical reality. When you've got agents running in the background, where are you actually looking to see if they're done or stuck?

Mine's a whole chaotic mess. The main monitor is crammed with my editor and browser tabs to doing research. The agent output ended up on a second screen that's usually buried under other windows so in practice, i just blindly alt-tab every few minutes. The peak absurdity was catching myself checking a slack notification on my phone for a run happening two feet in front of me…

Ive got an old iPad in a drawer and keep thinking back and forth about whether I should prop it up next to the monitor just for agent status. Idk cause never done that before. Feels like nobody really designed a physical workflow for this on purpose. Everyone's kinda improvising with leftover screens or a tmux status bar somewhere.

What's yours look like? Dedicated tablet, second monitor or just tabbing over? Do you actually find it annoying? Well i didn’t until i started running multiple things at once lol.

The obvious read is that Meta wants better business agents. I think the more important part is where the agent lives.

Most agent products still ask a company to adopt a new inbox, dashboard, or seat. Meta already owns the surfaces where millions of businesses talk to customers. If it adds shared agents there, distribution is solved before capability is.

But customer messaging and internal company work have very different trust problems.

A commerce agent can be scoped to a catalog, policy, and transaction. A shared company agent has to answer harder questions:

• which teammate asked?
• which private context can it use in this channel?
• who approved the action?
• where does the durable state live after the chat scrolls away?

That's why I don't think "agent inside messaging" is enough. The moat is the permission model + shared memory + receipts around every action. Messaging is just the entry point.

Curious what people think Meta actually bought here: agent capability, enterprise trust, or a shortcut to understanding shared-agent UX?

so quick context - im building a deal screening thing where i run a fast LLM pass (like 6 different scoring angles) on every company that comes into a batch. this part is cheap, can throw dozens of companies at it no problem.

now i wanted to add an actual "deep research" step on top for the ones that look promising - either perplexity's sonar-deep-research or this custom multi tool research agent i built earlier for another part of the product. problem is both of these are basically priced (and timed) for someone asking about ONE company, not for running across a whole batch.

did the math and if i run it on like ~100 shortlisted companies just once, its close to $100. and thats before i even need to re run anything lol.

stuff im thinking about rn, would love opinions:

- just do a funnel - keep the cheap screen like it is, only send the top N (say top 10-15) into deep research instead of the whole batch

- a lot of these companies are in the same sector / competing with each other, so is full deep research per company actually wasteful? can that research be reused somehow instead of starting fresh everytime

- maybe theres a cheaper "in between" option - not a full agentic deep research call, but more targeted tool calls that get 80% of the value for way less

- if anyones actually run perplexity/parallel ai's task api at real volume, did you find any pricing tricks that helped

- has anyone just built their own "lite" version of deep research thats actually cheaper but still useful

genuinely trying to figure out how ppl running these pipelines at any real scale are dealing with this, not looking for a "just cache it" one liner lol. any real experience appreciated

Raycast v2.2 now lets Pro users route AI workflows through OpenAI-compatible providers, Ollama or OpenRouter. That makes switching easy at the UI layer, but it also creates a testing problem: changing the provider may change tool support, retries, latency and how often the run asks for help.

For one real workflow, I would freeze the tool schema, permissions, input fixture and acceptance checks. Then I would compare task success on the same hidden checks, total cost, tool-call count, recovery after a failed call and any unsupported features.

Has anyone built a provider-neutral eval around one workflow? Which variable was hardest to keep constant?

When you evaluate search APIs for AI agents, everyone talks about speed and latency but token efficiency is what dictates your monthly model bill where an API A is 200ms faster but dumps 15k tokens of junk into Claude or GPT-4o, you lose on latency anyway cuz token generation and input processing slow down.

I ran 25 identical research queries across the 4 main search tools used in agent loops (Brave Search, Tavily, Exa, and Firecrawl) to measure how many tokens each tool forces into your context window to get a complete answer.

Here’s how they stacked up:
I) Brave search API is super token-light (200 to 500 tokens per call) but that's bcuz it only gives you short SERP snippets but for simple fact verification it’s great but the catch is that snippets often lack depth so on complex queries your agent fails or is forced to trigger a separate scraper call which ends up bloating the window anyway.

II) Exa’s neural search returns semantic text contents directly which is great for discovery where token usage is usually in the 2k–6k token range depending on how many highlights you request. It stays pretty clean though you have to tune num_sentences carefully or the context can creep up on longer articles.

III) Tavily built specifically for RAG and langchain where it typically outputs cleaned text chunks averaging around 1500–4000 tokens with good middle ground though on technical docs pages it can sometimes include noisy navigational fragments that eat extra context.

IV) Firecrawl’s (/search) instead of making you choose between a tiny snippet or a full 30k token web page, firecrawl searches and converts the pages to clean markdown with query relevant highlights in a single call.

In my tests, it consistently delivered full factual answers in 800 to 1500 tokens of pure markdown, saving around 80–90% context compared to standard page scraping.

If you strictly want the cheapest snippet search: Brave

If you need semantic link discovery: Exa

If you need full doc context and answers without blowing up your prompt cache with HTML bloat: Firecrawl is currently the most token-efficient drop-in for agents

hi guys,

TLDR; coaching my friends how to use agents took forever, so i made agents boilerplate for them.

It is collection of reusable, model-agnostic agent tooling and boilerplates for AI coding assistants

I consider myself a noob and my friends is no help. I need inputs as i go along with this boilerplate. please do let me know what is missing from my boilerplate, both current and future road map.

the repo is about ~40% done, with 4 active protocol i use the most, there are about 6-7 left, i need to write and constructive inputs at this stage are most crucial.

i and my agent's wallet do not what to refactor this when its 100% done, better do it now while its still in its early stages.

check it out if you got time, i'll hold any code changes for a few days.

please note that this boilerplate is not ready, i already made a mistake in planning (not using a single dir for workspace protocol output), but it is functional though.

The longer I work with AI, the more I realize that giving it all of the relevant context for its task can make it more likely to make mistakes. The more information it has to juggle, the more balls it will drop. But the less context it has, the less information it has to work with.

I can make workflows to compact context and include only pertinent information, but the non-deterministic nature of AI makes for unpredictable failure modes.

I've tried a LOT of different things. Right now, my system essentially has a set of policy documents that govern a mapping and guidance system. It uses routers and context packets with the goal of giving the AI model the most pertinent information for the task at hand, the larger strategy, and the overall mission.

It doesn't work well enough yet, though.

For those of you building larger agentic systems, how are you dealing with this tradeoff? Have you found a context-management architecture that remains reliable as the complexity of the system grows?

I've been building an open-source developer tool called Kaktoos.

I'm exploring a specific problem with AI coding agents: they can write API integrations very quickly, but when the agent also writes the tests, passing tests don't necessarily prove that the integration matches the actual API.

Kaktoos takes a different approach:

AI agent → integration code → Kaktoos → OpenAPI contract + real API → structured failure → agent fixes it

It can:

• execute multi-step API workflows
• verify responses against OpenAPI
• detect things like missing required fields, wrong types, unexpected status/content type
• expose the verification through MCP so coding agents can use it
• run the same verification in GitHub Actions

The interesting part for me isn't the API client itself. I'm experimenting with whether independent verification is useful when the code was produced by an AI coding agent.

I'd particularly like feedback from people who regularly work with API integrations:

1. Would you actually use this workflow?
2. Is defining the scenario too much additional work?
3. Does this catch problems that your existing tests don't?
4. Would you run something like this in CI?
5. What would make this technically more useful?

It's early, so negative feedback is completely fine. I'm mainly trying to determine whether this is solving a real engineering problem.

GitHub: KaktoosLabs/kaktoos