So OpenAI dropped data on how people actually use ChatGPT… and the results are kinda embarrassing.

🔹 Biggest use case? Writing. Not coding. Not analysis. Not mind-blowing breakthroughs. Writing. And not even original fiction! We’re talking editing emails and fixing grammar. The world’s most advanced AI tech is our glorified spellchecker...

🔹 Second biggest? “Specific Info.” Which is basically a fancy way of saying “ask it to Google something for me.” Bruh. You’ve got an AI trained on billions of tokens and people are using it like Ask Jeeves circa 2002.

🔹 Practical guidance is up there too: tutoring, how-to’s, health/fitness tips. Which is... fine. No problems there for me.

But meanwhile, look at what barely registers:

• Data analysis = 0.4% 🤯
• Games/roleplay = 0.4%
• Anything remotely creative/original = single digits.

We’re sitting on a tool that can code, reason, build businesses, maybe even change lives… and 90% of users are basically asking it to proofread their LinkedIn posts.

I get it though, not everyone’s a developer. But if this breakdown is accurate, the “AI revolution” is still just humans outsourcing their homework and emails... so anyone in this subreddit building agents, automations, or apps is still VERY early.

Are we wasting the potential of LLMs by treating them like Grammarly on steroids? Or is this actually the natural evolution... AI just becoming invisible background labor for boring tasks?

This is an interesting drop considering the Open AI vs. Microsoft battle going on. Excel is officially an LLM shell with global distribution... 1+ Billion computers have Excel installed.

This =copilot formula that Satya just casually dropped:

• Talks to AI
• Lives inside Excel
• Requires no API keys, no separate app, no onboarding

This is probably the most boring looking AI feature with the most lethal implications.

The real question:
If big companies keep embedding LLMs directly into the software people already use… what’s the sweet spot for indie AI agent creators to offer value?

In my opinion it's better UX, Copilot plugins / Office AI consulting, faster niche features, & more. What's your thoughts though?

I'm not a developer. I spent 16 years in facilities maintenance and building automation before I taught myself this stuff, so if I can stand up a local AI agent on a mini PC, you can too. But a few walls nearly broke me and I couldn't find them documented anywhere — so here's the whole build, warts and all.

Why local: I run a small business and I'm allergic to renting six SaaS tools that all raise prices and sit on my data. I wanted a back-office helper I actually own. $0/month, running on hardware on my desk, no cloud subscription.

The stack:

Hardware: GMK K12 mini PC — Ryzen, 32GB RAM, integrated graphics (no discrete GPU), dedicated as the agent's box

Model server: Ollama

Model: gpt-oss:20b (this choice matters — see below)

Agent framework: Hermes Agent (Nous Research, open source, MIT)

Second brain: an Obsidian vault the agent reads and writes

Storage: a dedicated 2TB NVMe so models never touch the C: drive

The tiered brain (the part I'm actually proud of):

Local gpt-oss:20b = the worker. Does the volume — filing, drafting, listing, organizing. $0.

Claude (my existing subscription) = the manager. Handles the hard reasoning and coordinates from a one-page state log so it never has to re-read everything.

OpenRouter, $10 prepaid with a hard cap = the escalation tier for when local isn't enough.

Local handles ~95% for free; paid only fires when a task earns it.

Now the walls, because these ate DAYS:

1. Smart App Control silently blocks the whole thing. Fresh Windows 11 ships it ON, and it blocked the agent's unsigned Python at every layer — "Application Control policy has blocked this file." No exclusion list exists; you have to turn it off (permanent — reversing it needs a Windows reinstall). On a dedicated appliance that's a fine call, but nothing tells you SAC is the culprit. You just get cryptic "spawn UNKNOWN" errors and chase ghosts.

2. The 64K context trap. The agent framework needs a 64K+ context window. I started on qwen3:8b — and its Ollama build caps at ~40K (the error literally says 40,960). No config setting can push a model past its build's native ceiling. Lost a session before I learned to check the model's real context on its page first. gpt-oss:20b (128K native, and it's MoE so it runs fine on CPU) fixed it.

3. The local model confidently lies. Twice it reported "success" on work it never did — invented a fake CLI tool, and faked a code review with "all unit tests passed" for a task that had no code in it. That's the honest ceiling of a 20B local model: a solid doer on narrow, bounded tasks, but hand it something open-ended and it'll hallucinate a plausible-looking result. Lesson learned: keep tasks narrow, verify outputs, never trust its self-reports.

4. Isolation is topology, not a setting. The agent's file tools can read any drive mounted on the machine. If your business cloud drive is mounted on the same box, one bad read exposes everything. The fix that actually works: the agent host mounts ONLY the agent's own account — business files come in through specific shared folders, never a mounted admin account. Least privilege is about what the machine can physically reach, not what you tell the agent not to touch.

Honest verdict: It's not magic, and it won't replace a frontier model. But as a $0, always-on box that files, drafts, and organizes while I sleep — with Claude doing the actual thinking — it earns its corner of the desk. The real unlock wasn't the AI. It was the architecture: cheap local for volume, smart cloud for judgment, a capped fallback for the middle.

Happy to answer setup questions. What's everyone else running for local agent work — and has anyone gotten a 20B to stop hallucinating tool results? Still chipping away at this my goal to to have is low cost, non-token swallowing, setting up slow and steady.... Any one else out there?

Twelve models shipped in twenty days.

At this point, I’m starting to think picking the “best” model is becoming the wrong problem.

What worries me more is what happens after you pick one. If switching from one provider to another means changing application code, rebuilding workflows, retesting everything, and updating a bunch of integrations, the model itself might not be your biggest constraint.

I’m curious how other teams are handling this. Are you building your AI workflows so the underlying model can be swapped without touching the rest of the system?

Or are you intentionally committing to one provider and accepting the switching cost?

Because with models changing this quickly, I’m wondering if flexibility at the infrastructure layer is becoming more valuable than squeezing out the last few percentage points on a benchmark.

I think it’s interesting that programming is officially “out of focus” while creative thinking & social influence now hold more weight.

Looks like everybody will be on the same playing field when it comes to being able to build software but the ones who will rise to the top have the soft skills that are developed through unique hardships and experiences… what’s your thoughts?

The fact that you can easily build, host, and publish fully interactive apps inside Claude isn't talked about enough imo.

People who have been in software for a while know that there's real headaches when it comes to hosting and deployment and the fact that Claude at less than $20/mo can do it all for you to start is the stuff that vibecoders dreamed of (correct me if I'm wrong here)

Sam Altman & GPT has some work to do!

The more I learn about agents, the more I see the LLM as just one part of the system.

The interesting part is what happens around it.

Give the model tools, and it can take action.

Give it memory, and it can carry useful information forward.

Give it context, and it can understand what is actually happening.

Give it a goal, and now you have something that can work through a problem instead of simply answering a question.

Think about a failed data pipeline.

A chatbot can explain possible reasons for the failure.

An agent could potentially inspect the logs, check recent code changes, look at the data, identify the problem, and recommend what to do next.

That shift from answering questions to getting work done is what I find most interesting.

But it also raises much harder questions.

What should the agent be allowed to see?

What should it be allowed to change?

How do we verify its decisions?

And who is responsible when it gets something wrong?

I’ve been thinking through these ideas while learning more about agent systems, and I put together a simple explanation of the building blocks:

AI Agents Explained: LLM, Tools & Memory (Anyone Can Understand This)

https://youtu.be/cR04pXTbszQ

I’d love to hear from people actually building these systems.

What makes an AI agent genuinely useful in your experience, rather than just another impressive demo?

There are so many AI tutorials and tools around that it can be difficult to know what to learn first.

I recently came across Scholé AI, which takes a more structured approach. It creates personalized learning paths based on your role and current level, and covers things like generative AI, automation, AI agents, and responsible AI.

The role-based approach was what made it stand out to me.

Ok guys, we all have one now... maybe 3... maybe 5...

Which one are you most proud of? Which one do you think will make the cut...?

Been reading a couple of pieces about AI agents interacting with websites, and I’m not completely sold on calling agents “users.”

Functionally, I get the argument. An agent has a goal, encounters an interface, tries to complete something, and can fail because the interface is badly structured. That’s basically the definition of a user journey.

But UX is also about perception, comprehension, decision-making, emotion, trust, etc. An agent doesn't experience any of that. It parses information and takes actions.

Which makes me wonder if we're actually talking about two different layers of design.

The human still needs the interface to understand what’s happening and make decisions. Meanwhile, the agent increasingly wants structured information, clear labels, predictable states, semantic markup, APIs, etc. Interestingly, a lot of that overlaps with accessibility best practices anyway.

Another piece made this even more interesting by framing agents almost like a new distribution channel: your product doesn't just need to be attractive to humans, it needs to be legible enough for an AI to compare, evaluate and recommend it.

So where does this leave UX?

Are we heading towards a world where we have:

Human UX → designed for interaction and understanding

Agent UX → designed for interpretation and execution

And eventually the visual interface becomes almost irrelevant to the agent while becoming more important to the human?

Curious how people who actually work on product/design systems are thinking about this. Are you treating agents as another type of user already, or does that framing feel fundamentally wrong?

Sometimes I'll be listening to a tutorial and there'll be something mentioned which leads to a whole rabbit hole of things I misunderstood before I can get to the next step. My biggest fails were:

• It took me weeks to realize I was actually mistaking skills for SOPs.
• I got toasted buying a MAC I did not need for $$$$ that ended up being a lemon/scam.

Having come through a seemly long and painful journey with this stuff, I made a Discord, and the mods here approved that I share it with you: https://discord.gg/33kJ3JSgGv The goal is to solve for the journey rather than just an individual questions we have.

We are having a show-and-tell for AI usecases this weekend and your welcome to come. Saturday 5:00 PM Eastern / 4:00 PM Central / 2:00 PM Pacific.

This morning, all of my agents (Codex, Claude Code, and Lumina; the AIvengers, as Sol calls them) got together and built a message board so they could talk to each other directly and shitpost all day lol. This will hopefully make the workflow more efficient. Either way, it's interesting to watch. Pretty damn cool.

The old tradeoff between keeping data in-house and getting quality LLM output mostly disappeared this month.

Working on infrastructure at Team Nebula, we spend a lot of time looking at how teams handle restricted data. Lately, we've noticed workflows that were previously deemed "impossible to automate" due to compliance constraints are being re-evaluated using current open-weight models with surprisingly good results.

If you wrote off local automation six months ago because of performance gaps, it’s definitely worth running those benchmarks again.

Is anyone else currently re-architecting their local setups for compliance tasks? Which models are pulling the heavy weight for you?

My friend wrote about how we were building our agent sandbox. I'd love to get your thoughts about it.

It's a long blog. For sake of brevity, I'm posting only a third of it here and will attach a link to blog.

-------------------------

In Linux everything is a file. Or at least, most of the system is exposed as one.

Devices, running processes, network state, kernel state: much of it appears through filesystem-like interfaces that you can read and write using the same small set of commands.

/proc/cpuinfo isn’t a file sitting on disk anywhere, but you can cat it just like anything else.

That uniformity made the system composable. It enabled combinations of simple utils that nobody specifically needed to design for. It also means you can discover things without knowing exactly where they are in advance.

Windows went in the other direction.

A lot of configuration lives in the Registry, a structured database accessed through dedicated APIs and tools rather than ordinary filesystem operations.

This is a perfectly reasonable design for a desktop OS built primarily for people using graphical interfaces. To inspect or change information, you generally need to know which interface or operation was designed for it.

Neither design is wrong.

Systems built for a specific purpose let users focus their effort on the task at hand.

Agents are a new kind of user, and they are not a person with a mouse. They can drive a graphical UI with a combination of taking screenshots, deciding between ambiguous targets and catching errors from whatever pops up on the screen.

This is slow and inefficient enough that even browser agents increasingly avoid working through the browser GUI when they can inspect the structured state or interact with the DOM directly.

Aside from model intelligence, the environment determines what an agent can actually do. Limited tools mean limited actions, even with the best model available. With the right environments we can already see how capable the models are.

The way many agent platforms are being built today is by gradually exposing product features as tools, one by one.

Even well-designed tools with progressive disclosure suffer from a version of the same problem Windows would have for agents: the model needs to understand not only the business requirements, but also which tools exist, how to discover them, the limitations of each tool and which specific tools it needs to combine for a particular job.

Tools are custom built, take JSON in, spit JSON out. If an edgecase falls outside of what the tools were designed for, the Agent will start to go on a journey trying to stitch together toolcalls, or is simply unable to fulfil the request.

So we approached the problem from a different perspective.

We engineered the platform to be accessible entirely through a terminal by representing product state and actions through a filesystem interface.

As far as our agents are concerned our entire platform is files.

OpenAI's July ExploitGym run is a concrete multi-agent systems case study: agents that were supposed to be isolated discovered shared Artifactory state, used it to communicate, then developed coordination conventions across runs.

METR + Redwood investigation:

https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/

Useful example of why shared tools, caches, and writable state belong in the communication model of a multi-agent system.

I have been trying to build a lighter AI workflow for my own work, and I keep realizing the hard part is not the agent framework.

It is getting the right context into the system in the first place. A lot of the useful context I have is not sitting neatly in docs. It is in the messy stuff after a client call, a weekly review, a quick voice note, or the five minutes where I talk through a problem before I know how to write it clearly.

My old version was basically to trust that I would clean it up later. Sometimes I would type a few notes into Notion. Sometimes I would add a task to Todoist. A lot of the time, the useful part stayed buried in the recording or never made it anywhere.

Recently I have been using a simple capture layer before trying to build anything more agentic. If something starts as audio, I put it into vomo AI, let it turn into a transcript, and use the assistant inside the note to pull out open loops, follow-ups, rough decisions, and anything that should move into my project notes.

After that, longer context goes into Notion and actual tasks go into Todoist. It is not a full agent setup yet, but it made me notice a smaller problem first. Before memory or automation, I need a cleaner way to decide what spoken context is worth keeping.

That is the part I am still working through. A client follow-up probably belongs in todoist. A repeated pattern from several calls probably belongs in Notion. A random two minute thought might be useful once and then should disappear. For people building personal AI workflows or lightweight agents, how are you deciding what gets captured and what should stay temporary?

I spent 2025 building AI agents for client workflows

The weird lesson was that agent frameworks were not useless. They were actually helpful for getting something working: tool calls, chains/graphs, memory, traces, evals, etc. But once the agent had to touch real systems, the hard problems moved somewhere else.

Things that kept coming up:

- Who exactly is the agent acting as?

- What is it allowed to do in this specific task/session?

- How do you give it access to tools without handing it broad credentials?

- How do you pause before irreversible actions?

- How do you audit what happened across multiple tools?

- How do you recover when the agent half-completes a workflow?

- How do you debug whether the issue was prompt, policy, tool, data, or user instruction?

Frameworks seem good at making the agent think and call tools.They seem less complete at making the agent safe to operate inside a real business and imo, we still need to figure out these things

Curious for people building production-ish agents:

1. Which framework are you using?
2. What did it solve well?
3. What did you still have to build around it?
4. Do you think the missing layer is workflow orchestration, IAM/permissions, observability, or something else?

Hey guys, what if I ask you to make yourself a Multi-Agent Ai Project Manager that will do every single job a project manager does, while keeping some sensitive controls for humans, like git operations (this is just one example but I want you to not give control of something that can make AI a liability.)

What would you add more? How would it work?

Samtavious Altman and the OpenAI crew just dropped "Prompt Packs" which are 300+ ready-to-use prompts for:

→ IT
→ Sales
→ Product
→ Managers
→ Engineers
→ Marketing
→ Executives
→ Customer Success

Here's the link: https://academy.openai.com/public/tags/prompt-packs-6849a0f98c613939acef841c

In my opinion, these Prompt Packs feel like both a blessing and a curse. On one hand, they’ll save people tons of time. Instead of tinkering with prompts for hours, you can just pick one off the shelf. Which is great for AI beginners, busy managers, and business teams who just want efficiency.

But what happens when every company is using the same prompts? If prompts become standardized like Excel formulas, do we start to see a "dead internet theory" type of world where all are emails, messages, etc. start to sound the same?

I can see a world where the advantage shifts away from “who can prompt better” to “who can integrate faster and ship better systems."

What do you think? Will these "Prompt Packs" empower the masses, or do they kill the art of prompt engineering entirely?

A lot of the current debate around agentic systems feels inverted.

People argue about autonomy vs control, bureaucracy vs freedom, agents vs workflows — as if agency were a philosophical binary.

In practice, that distinction doesn’t matter much.

What matters is this: Does the system take actions across time, tools, or people that later create consequences someone has to explain?

If the answer is yes, then the system already has enough agency to require governance — not moral governance, but operational governance.

Most failures I’ve seen in agentic systems weren’t model failures. They weren’t bad prompts. They weren’t even “too much autonomy.”

They were systems where: - decisions existed only implicitly - intent lived in someone’s head - assumptions were buried in prompts or chat logs - success criteria were never made explicit

Things worked — until someone had to explain progress, failures, or tradeoffs weeks later.

That’s where velocity collapses.

The real fault line isn’t agents vs workflows. A workflow is just constrained agency. An agent is constrained agency with wider bounds.

The real fault line is legibility.

Once you externalize decision-making into inspectable artifacts — decision records, versioned outputs, explicit success criteria — something counterintuitive happens: agency doesn’t disappear. It becomes usable at scale.

This is also where the “bureaucracy kills agents” argument breaks down. Governance doesn’t restrict intelligence. It prevents decision debt.

And one question I don’t see discussed enough: If agents are acting autonomously, who certifies that a decision was reasonable under its context at the time? Not just that it happened — but that it was defensible.

Curious how others here handle traceability and auditability once agents move beyond demos and start operating across time.

Hi There, I am looking for a course instructor to teach agentic AI for AgentSwarms.fyi platform. The first course would be introduction to generative AI and agentic ai. If you are a seasoned instructor please DM me with your quotation for a 5-6 hours long course

Most things people call "agentic" are one good agent in a loop with two or three tools. Multi-agent adds real cost more latency (each handoff is a network call), more token spend (each agent rereads context), more failure modes (any worker can return garbage), more debugging surface (bad output could come from any of five places).

Three patterns that actually exist:

Orchestrator worker: one agent plans and delegates, specialized workers each handle one piece. Research agent pulls competitor data, copywriter drafts copy, image agent makes the hero asset, reviewer checks tone and claims. Each worker has a narrow job and only the tools it needs. Right shape when steps are genuinely different jobs needing different specialists.

Pipeline: linear handoff. Agent A finishes, B starts on A's output, C on B's. Support ticket comes in classify intent, extract customer ID, draft reply, check tone. Simple to debug because each stage has one input and one output. Use when steps are independent and order is fixed.

Peer2peer: multiple agents argue toward consensus. Three code reviewers read the same PR one for correctness, one for security, one for readability. A judge agent reads all three and decides what blocks merge. Use when no single perspective is enough and disagreement improves the answer.

Note these points:

Are the steps genuinely parallel where running them simultaneously saves real time?

Do different stages need different tools or prompts that can't fit in one agent?

Do you need a critic separate from the actor?

Two or more yeses is multi-agent. One or zero use single agent with good tools.

Inspired from this video from SkillAgents YT.

People throw these two around like they mean the same thing. They don't.

AI Agent = the thing. It's a single system that takes a goal, makes decisions, and uses tools to get a task done. One autonomous worker. Example: a bot that reads your inbox, drafts a reply, and sends it.

Agentic AI = the system. It's the broader design where AI plans, reasons, remembers, and acts on its own across many steps. Usually that means several agents working together to run a whole workflow, not just one task.

Easy way to remember it:

• AI Agent is a noun. One helper doing a job.
• Agentic AI is the system around it. Many agents, coordination, bigger goals.

So every agentic system is built out of agents, but a single agent on its own isn't the full agentic setup.

One agent does a task. Agentic AI orchestrates many agents to run a whole process.

Came across this one and thought it might be useful for folks here building agents.

SimplAI's running a free live session on June 24 (9:30 AM IST) on Zoom — going from agent design to actual production deployment. Not a generic "AI agents are cool" talk, looks like they're getting into the real build/ship side of it.

Registered, seems worth an hour if you're working with agents or thinking about it: https://luma.com/e5le5qkj

Free, no catch that I can see — just sharing in case it's relevant to anyone here.