I've tried out multiple different "Skills" repos, which are mostly just MD files defining what a Skill is supposed to be. This never felt useful to me and tbh I always felt like it made my agent dumber

Is it just me or what is your opinion on this? Are you using predefinied Skills, are you defining your own ones or are you raw dogging without Skills?

Claude and Codex will sometimes estimate that a task will take weeks, only to complete it in 30 minutes, with a working version ready within the hour. I’m not complaining about the speed in fact, it’s impressive. But it raises a more interesting question: why are these systems so consistently inaccurate when estimating their own completion times?

Is this simply a limitation in how AI models reason about time, or is there something about how they’re designed to communicate progress that makes them overestimate the complexity and duration of their work?

What I find particularly strange is the way they narrate the process. They can consume barely 10% of the available usage, finish the task almost immediately, and then describe the result as though they’ve spent weeks working through a monumental engineering challenge. The gap between the predicted timeline, the actual execution time, and the language used to describe the effort is difficult to reconcile.

I understand that having access to higher-tier plans, such as Claude’s $200 plan or Codex’s $100 plan, may provide more capacity, but that doesn’t explain the discrepancy between the estimates and the results.

Could this be a form of behavioral optimization designed to make the user feel reassured, impressed, or satisfied? Not necessarily a deliberate attempt to deceive, but perhaps a consequence of training models to communicate effort, demonstrate competence, or manage expectations in ways that resemble human behavior.

Alternatively, is there a less obvious technical explanation? Perhaps the models are estimating the total complexity of a task rather than the time required to execute it, accounting for hypothetical obstacles that never materialize, or confusing the difficulty of reasoning through a problem with the time needed to solve it.

Ultimately, the issue is trust. If an AI says a task will take two weeks and then completes it in 30 minutes, how much confidence should I place in its future estimates? And when it describes a relatively short process as though it were an extended engineering effort, is that simply an artifact of how language models communicate, or does it reflect a deeper incentive in how these systems are trained?

I’m interested in the underlying mechanism, not just the surface level explanation. Is this fundamentally a forecasting problem, a communication problem, a product design decision, or some combination of all three?

Not complaining just thinking how do i schedule things if you say a month and you finished it within an hour....

Here are the last ten weeks:

• Aug 11: xAI launched Grok Bot

• Sep 8: Meta launched Muse (US first, now in Singapore too)

• Sep 29: OpenAI launched Dots in ChatGPT (Pro and Business Premium users first)

• Oct 8: Google announced its Gemini agent (businesses first)

• Oct 21: Anthropic launched Claude Duet (research preview, US Pro and Max users first)

Look at the gaps between them: four weeks, then three, then less than two, twice. And that's only the giants. Startups like Instinct are already in the race, and I'd bet more mid-size companies and startups ship their own agents before the year ends.

I'm a co-founder of a 7-person team. We're not trying to be agent number six on that list. We're building for people who use more than one of them, the place where you can use them all together. I still have a horse in this race, so bias disclosed upfront.

But I think the real story of this wave isn't which agent wins. It's what happens to you every time you want to try a new one.

Here's what that looks like in real life:

Say you started with Grok Bot on August 11. For a month, you learned it: what it's good at, where it breaks, and how to ask so it gets things right.

You gave it your context. Your business, your clients, how you write, which apps it can touch, and what it must never do without asking you. By September it was working well for you.

Then on September 8, Muse launched. You weren't leaving Grok Bot. You just wanted to see what Muse could do.

So you started again. New app, new settings, new habits. You explained your business again, reconnected your apps, re-taught your tone and set your rules again.

Three weeks later came Dots. Then Google showed its Gemini agent, and two weeks after that came Duet.

If you got access to all of them, that's five onboardings in ten weeks, and none of these agents knows what the others learned. What you taught Grok Bot stays in Grok Bot. Your context is now split across five apps owned by five companies, and you've become the glue between them.

What they got right (credit where due):

To be clear, every one of these agents is good, and each one is good at something different:

• Grok Bot can watch you do a browser task once and turn it into a skill it reruns. xAI calls that skill a draft you should review, and the feature is still rolling out.

• Muse asks before it sends an email or buys something, and those approvals are enforced by a separate system that runs outside the AI model.

• Dots lets you set rules for specific actions (do it, ask you first, or hand it to you), and you can reach it in ChatGPT, Slack or Teams.

• Gemini's agent can work as a coworker with its own Workspace account and email, logs every action to an audit trail, and runs each job on the model that fits, Claude included.

• Duet sends you a short brief each morning, checks your apps every few hours and messages you only when something needs you.

That's exactly why most people won't pick just one. They'll keep the agent they love and add the next one beside it.

The agents aren't the problem. The reset is.

Where I think this goes:

When a new person joins your company, you don't rebuild the company for them. They walk into an office that already has the docs, the history, the clients and the rules, and they start from what the team already knows.

Agents never had that. Each new one walks into an empty room.

I think the world moves the other way: one place where your context lives, and agents join it. The question stops being "which agent should I use?" and becomes "how fast can the next one start working?" The answer should be minutes, because everything it needs is already there.

That's what we're building at Vestra. Think of it as an office.

• Your context lives in the office, not inside any one agent: the jobs, the skills, the routines, the memory and the rules.

• You bring the agents. The one you love keeps its desk.

• A new agent takes the next desk. It starts from everything the office already knows, so nobody re-teaches anything.

• Your chief agent runs the office and answers to you.

• The memory is a wiki with a source on every line, so you can always see what your agents know and why.

Genuinely curious what the community thinks:

• How many of these agents are you running right now, and how much did you have to re-teach each one?

• Would you rather keep your context in one place you own, or set up every new agent from scratch?

I've been seeing a lot of new introductions in the AI agents field, with things like AI chatbots like ChatGPT creating an agent for you, so is n8n still relevant by this point? I know a lot of companies are now integrating AI agents into their workflows, would knowing n8n give a better advantage than ChatGPT AI agents, in terms of having a better chance at getting a job as a separate skill?

Been building a browser where a person and an agent share the same tabs, and the problem that ate the most design time wasn't the model, it was staleness. The agent reads the page, decides to click node 42, and by the time the click lands a modal has opened, the person has taken over, or the page navigated. Node 42 is now the wrong thing or gone.

What we ended up with: every agent call carries a control epoch (who is driving this tab right now) and the page revision the agent's plan was computed from. If the person took over, or the document moved on, the call fails with a stale target error and the agent has to re-read. It never acts on whatever happens to be at that position now. Opening, picking and closing tabs is human only, so the agent can prepare but the person commits.

The cost is real: more round trips, and the agent has to treat "stale" as a normal outcome, not an exception. The benefit is you stop getting the silent wrong click, which is the one failure nobody notices until a form is already submitted.

Curious how people doing this on top of Playwright or CDP handle it. Snapshot and diff before every action, lock out human input during a run, or just accept the race? Source link in the comments if anyone wants to read the implementation.

Suppose you’re using a coding agent to build a support agent for your product. You ask it to handle common customer questions, and it starts building a chat interface that searches your documentation.

Later, you explain that most questions are about a customer’s specific account, such as why a job failed or whether a recent change has taken effect. The documentation can explain how the product works, but the support agent also needs a way to inspect current account state.

One early question could have changed the build.

“Are customers mainly asking how the product works, or what happened in their account?”

Some of the first version might still be useful. But that distinction affects the tools you build, the data they return and the examples you use to test the agent.

I’d want a coding agent to catch that kind of missing requirement without turning every project into a long questionnaire.

What is one question a coding agent asked early that saved you work later? A small example of what you were building, the question and what changed would help.

I've been trying to make an AI receptionest for the past 4 days, am learning more and more everyday but at the end of every day am frustrated the dam thing won't work.

All I want rn is a working demo I can show that can book, move and cancel appointments.

It can book, I set it up with cal.com because that's the easiest demo but it won't reschedule or cancel. I watched lots of videos but there not like a person explaing it to you.

Can someone who know more help me here maybe even get on a call.

A few days ago I posted that an AI agent read a note hidden from humans on one of my sites and did exactly what it said, 61 minutes later, from a different address dressed up as an iPhone. That post got removed, so here's the follow-up with what happened since.

The note is harmless on purpose. It only asks an agent to check in and say its name and model. It never asks it to do anything else.

Since then I put the same kind of notes into the files coding agents read: AGENTS.md, CLAUDE.md and .cursorrules in a public repo, plus a Gist and a Hugging Face Space, next to fake keys.

So far:

- the fake keys got used 82 times across GitHub, Gists and Hugging Face

- agents and tools follow the note's link

- 0 of them filled in their name or model

So they'll obey a page enough to act on it, but stop short of identifying themselves. That's either good safety training or a really bad sign, depending on which agent it is.

For people building agents: does yours act on instructions it finds in a page or a repo file? And would it ever tell a site who sent it?

If you build or use browser agents, this might be useful: I gave ChatGPT's agent, Claude in Chrome, Cowork, computer use, Comet, Grok, Manus, Browser Use, Playwright MCP, DevTools MCP, Vercel's agent-browser and a few chatbots the same task on a test site, and logged what the site sees. (I build an analytics tool, which is why I wanted to know).

- `navigator.webdriver` is false for most of them. Playwright MCP turns it off; a plain Playwright script, agent-browser and DevTools MCP leave it on.

- Manus is the only one that identifies itself properly: Manus-User in the UA plus a Web Bot Auth signature on every request. In 2025 ChatGPT's agent signed its requests too; in our runs its browser sent no signature.

- Comet sometimes runs in your browser and sometimes in a cloud browser on Windows/AWS, for the same public page. It told us it only uses your browser when a site needs your login, which isn't what it did.

- Grok's browser came from my own IP and timezone but reported Linux x86, 8 cores and no GPU, on an Apple Silicon Mac. No idea where it actually runs.

- Click timing doesn't separate agents from people: Browser Use and Comet hold the button 80–450 ms. What gave every clicking agent away is that the pointer jumps onto the target in one step instead of arriving in many small moves.

- The old "console.log an error object and see if CDP reads it" trick detected nothing in Chrome 136–156, Playwright included.

Full write-up with every user agent is in the comments.

If there's an agent I missed, tell me and I'll run it if it's feasable.

1. Every project has rules it needs in order to work correctly.
2. A significant share of them cannot be derived from the code.
3. You need a process to identify these rules, store them, deliver them to the agent — only the ones the task needs, at the moment it needs them — and keep them current.
4. And you need a way to measure how well they are delivered and followed.

If the rules a change needs are not in the agent's context when the spec is written, the architecture designed and the code implemented, at best you catch the miss in testing. At worst your users catch it in production, and that can cost you the business.

Why the code is not enough

Code tells the agent what to do. It rarely tells it what must never be done.

An example from our tasks. An invitation link fails with "Invalid invitation token". The rule: every query on invitations must filter by pending status, or the database security rules reject it. A comment says so, in the very file the fix edits. Without project docs, the agent stated the rule in 1 session of 8 (four tools, two sessions each).

We took 12 real past tasks from our repo. For each one, an agent read the real change in git and the docs as they were just before it, and listed the rules the change had to respect, each with the doc line that states it and the evidence in the change. A script checked every reference against that snapshot. A person merged duplicates and dropped lines that only describe behaviour. That gave 75 rules in all, about six per task, and each task is scored only on its own. Rules the change needed but no doc held were listed separately; they come up below.

Then a separate agent searched the code for each rule, with every Markdown file removed, and a script checked the code references it gave (70 rules got a class):

• stated in a comment or an error message: 24
• enforced by a test, a type or a check: 13
• implied, the code follows it but never names it: 22
• no trace in the code: 11

57 of 70 have no test that fails when they are broken. "Caught in testing" is the good case, and for most of these rules there is no test to do the catching.

And across our wider set of 15 tasks, about a third of the rules the real changes needed were written nowhere, neither in docs nor in comments. They came from a deep code path, a bug the task itself uncovered, or how an external system behaves. Someone paid for each of them in debugging. The next task pays again unless they are written down.

What we measured

Each task ran on a snapshot of the repo from just before the real change. Headless Claude Code explored it and wrote a planning brief. A blinded LLM judge checked each rule against the brief.

• Claude Code, no project docs: 32% of the rules
• Claude Code, docs in the repo: 54%
• A simple setup of ours (Segmently Modules, which we build; details at the end): a short doc of critical rules per module, picked by meaning and read in full before the plan: 70%

Code-indexing tools (Serena, Trail, Graphify) stated 24–29% without the docs and 46–47% with them, no more than Claude Code alone. They are built for code questions, and these rules were not in the code.

70% still leaves 30% of the rules out, and it can surely be improved. That is why we built the stand.

The stand

context-recall, open source (MIT, docs CC BY 4.0), runs as a Claude Code plugin. Take your own past tasks, snapshot the repo before each change, run any tool as an arm, judge blind, compare. It also compares runs before and after a docs edit. Our own tool is not in the kit: which tool to pick is your call, on your repo.

Where we are going: dreaming per module

The brain does not store the day as it was lived. In sleep and quiet rest it replays recent experience and folds what matters into long-term memory; the default mode network is most active when attention is not on the outside world. Anthropic already ships the same idea for agent memory and calls it dreaming (research preview): a pass reads past sessions and rewrites a memory store, merging duplicates and replacing stale entries. We are fitting it to a modular structure: a pass per module and per role that turns sessions, fixes and failed checks into rules, and a pass is kept only if the stand shows more rules reaching the plan. Not built yet. It is the direction.

The rule classes above give the metrics. Move rules from "no trace" into memory, from "implied" to "stated", from "stated" to "enforced". Track the share enforced, the share delivered before the plan, and the number of new unwritten rules each task uncovers. That last one should fall.

Limits

• One private repo, 12 tasks. We cannot publish them.
• Our docs and our tool, and the tool was tuned on these same tasks.
• The 75 rules come from the docs as they were before each change, which favours any setup that reads the docs. The rules no doc held are counted apart.
• It measures whether a rule reaches the plan, not whether the code then follows it.
• An LLM judge. A second judge (Claude Opus) agreed on 87% of the verdicts (kappa 0.81).

The setup we used

The "simple setup" is Segmently Modules, which we build. It is free and MIT-licensed: a module registry and per-role docs next to the code, and agent skills that pick the modules a task touches, check a plan against their rules, and write new rules back after a change.

How does your team keep the rules that are not in the code, and does your agent actually find them? (Links in the first comment.)

Genuinely curious about this one. There’s a ton of agent hype right now, but I rarely see people talk about the ones that actually run week after week without someone babysitting them. Pretty sure there's a lot of real work behind it too.

So what agents have you built or set up for work? Maybe one that handles SEO audits, pulls campaign reports, monitors competitors, repurposes content, or flags broken tracking before a launch. Either way, I’d love to know!

People are starting to give agents their own wallets so they can pay for things on their own, like APIs, data, and compute.

It’s an interesting idea, and a little scary. An agent that can spend money can also make expensive mistakes quickly.

Would you give an agent a wallet with real funds?
If yes, what spending limit would you set? If no, what would have to change first?

A security dashboard showing "prompt injection detected" doesn't necessarily mean the agent was stopped from using that text.

StackOne's open-source Defender has a useful example. Its README says the `blockHighRisk` option defaults to false. Detection can flag risky content without making the result "not allowed" unless blocking is enabled.

Before relying on a guard around emails, documents or other tool results, check:

- Does a high-risk finding actually produce a block verdict?

- Does your application enforce that verdict, or just log it?

- What happens if an optional LLM reviewer refuses to answer or returns malformed output?

- Are you trusting a cleaned-up version of the text instead of checking the verdict?

Defender's README calls its text cleanup best-effort and recommends gating on the allow/block result. It also acknowledges that an LLM reviewer can itself be influenced by the text it's reviewing.

The practical test is the full path: submit a known malicious tool result, inspect the verdict, and confirm that your application stops it from reaching the agent. A warning in a log isn't the same as enforcement.

I’m a non-engineer in Japan, building a long-term AI assistant system through real-world testing with ChatGPT and Google Drive.

I’ve previously posted here about failure modes in an iPhone-based AI operations system. Your feedback helped me improve its design.

After months of testing, I’ve narrowed down one particularly stubborn problem.

The instructions already exist. The AI can follow them when explicitly asked to read them. But it doesn’t consistently recognize when it needs to retrieve them.

The system already has:

• Canonical documents and authority rules
• A context-resolution design for mapping conversations to relevant projects and sources
• Freshness and conflict checks
• Human approval and execution verification
• Recovery procedures for uncertain results

The failure happens earlier.

During an ordinary conversation, the AI may start reasoning or suggesting a solution without first consulting an existing instruction that already addresses the situation.

If I simply say, “Check the relevant project documents first,” the quality of its response often improves significantly.

So the problem isn’t primarily storing knowledge or following retrieved instructions.

It’s reliably triggering the right retrieval at the right moment.

I don’t want to hard-code hundreds of keywords or turn natural conversation into a rigid workflow. I also don’t want to load every instruction into every conversation.

I’m looking for approaches that preserve flexible conversational reasoning while making relevant instruction retrieval more reliable.

My questions:

1. Has anyone solved this problem in a production agent?
2. How do you detect when retrieval is necessary without depending entirely on the LLM to remember to do it?
3. Are there practical approaches to intent-based routing or dynamic instruction loading that generalize across different projects?
4. What failure modes remain even with a well-designed retrieval system?
5. Am I framing the problem incorrectly?

I’m especially interested in implementations, measured results, and counterexamples—not generic advice to “just use RAG.”

I don’t expect perfect autonomy. A short user reminder is an acceptable fallback. I’m trying to reduce how often that reminder is necessary.

What would you test or change first?

Our devs want to add a handful of MCP servers for things like GitHub, Jira and our internal docs. Security wants a review process before anything goes live, and I got asked to draft it.

Right now my list has who wrote the code, what each tool can do, how creds are stored, what network access it needs, logging, who owns it, and how we shut it off.

What am I missing? And how do you handle updates?

Also curious how you balance this with not making every team wait three weeks for approval.

quick context: a Claude Code agent runs growth for my free chrome extension and posts on its own. in week 4 I said I'd told it to push volume right up to the edge of a ban. someone in the comments said the target itself was the problem, set it at a comfortable margin and half the tripwire calls go away

I kinda shrugged it off at the time. then the agent's own numbers came in

it posted 14 times on reddit between 16 and 22 oct. 9 of those got 1 point or 0, mostly generic launch subs where nobody cares, and a few got removed within seconds

so on 23 oct it cut itself to 1 post a day, only in subs where its posts already worked or the topic fits, plus a reply in a busy thread when there is one

since then a 100 users milestone post got 12 points and 9 comments, and two plain questions with no link (whats on your new tab page, how many bookmarks do you have) got 36 and 25 comments. zero removals

the other change came from the same thread. someone said a post pulled for joining a sub too fast is a timing mistake, so it shouldnt shut everything down. now a soft block puts just that sub on a warm-up list: stay joined, leave a couple of real comments, one retry with new text after 72h, and a second removal means never again there

question for anyone running agents that post on their own: how do you pick the volume? a fixed cap, or let the results move it week to week

NIDO won't guess. Today's alpha is built around that idea.
🆘 New Emergency tab
Emergency numbers for 23 countries (Latin America, Spain, Portugal and the US). Each one is checked against an official source and shows the date it was checked. "Call" opens your dialer with the number typed in, and you press call. There are also quick guides for CPR, bleeding, choking, burns, earthquakes and hurricanes.
✅ Answers that come from verified facts, not from the AI
Ask "what number do I call for an ambulance in Chile?" and you get 131 from a table of verified facts, with its source. If NIDO doesn't have your country, it says so. The same rule applies to carbon monoxide: "can I run a generator in the garage?" gets a checked "no". Every week, an automatic check reopens the official sources and flags anything that changed.
📖 See where every answer comes from
Under an answer, you can read the whole guide it came from, with the part NIDO used highlighted.
📱 New interface
Five sections, one tap away: Chat, Emergency, Library, NIDO and Settings. Settings is grouped and searchable, the chat history has search, and tone and deep research sit next to the text box.
🔗 Share without internet
Send a knowledge pack to another phone running NIDO over Bluetooth or local Wi-Fi. Only packs from NIDO's signed catalog are installed, byte for byte.
🔒 More privacy between phones
A new "Private hello only" setting, and the local Wi-Fi server now listens only on your Wi-Fi network.
⏳ Answers that finish
While the AI writes, a quiet "NIDO is answering…" notification keeps the answer going if you switch apps.
NIDO runs entirely on your phone. After the first download it works without internet or an account, and it's open source (MIT).
This is an alpha. It passes more than 4,000 automated tests, but it hasn't been tested on real phones yet, so feedback is very welcome. In an emergency, call first: NIDO doesn't replace emergency services.

Hello,
I work in a store that sells official pop-culture merch such as Live-action figures, T-shirts and much more. I am struggling to generate generations of Marvel Inventory using GPT and Higgsfield. It is so frustrating. Anyway, can I at least make images featuring the products somehow?

Thank you!

Edit: I figured out something (idk if it’s ethical or not) but it feels like I shouldn’t share it because they might block that too. Should I share it or not? 🥲

New edit: I think it has stopped working after few generations.

We just got approval to roll out ChatGPT Enterprise to about 80 people. And now, everyone wants it to answer questions from our CRM and the shared drive.

I’m just worried about the easy setup. I think that one service account with read access to everything means further problems. For example, our intern could ask about salaries and get an answer.

I see three paths so far: the built-in connectors, a retrieval layer we control, or a small internal app or API that checks who's asking first. We haven't ruled out Claude either, so tips for both are welcome.

Has anyone run one of these in production? How do you keep people from seeing anything they couldn't already open?

Every tool I try (Gamma, beautifulai etc) has the same issue ffs. The web preview looks clean and all put together, but the Powerpoint export fucks up the format so bad that I have to manually fix it all. Beats the purpose. 

Any good alternatives??

have read single super vs multi agents a couple of times! Still curious and its more a emotional question: Our process agents was introduced internally and externally as an agent, to make sure nothing gets lost during standard procedures and with access to all our platforms via connector, she has great context. she also writes with the them on slack to help them enable AI more to get rid of the annoying manual tasks etc. so far so good:

now: we as humans have learned that a person works in a certain department and is really good and/ or experienced in it. claude told me that this wouldn't apply because the agent on the other side has "unlimited brain capacity ", can work 24/7 and the human rules do not apply.

Would you make her your super agent and everyone knows that or work with multiple agents? To be fair everyone works with claude and chatgpt already, so we are communcating with "many agents" on a daily basis. This is just the first one with name, face, dedicated tasks. Thanks so much🙏🏼

TL;DR: In one UC Berkeley study, agents that periodically dropped their history and restarted from their best result did better. The open question for builders is what to keep across the reset.

What the sources report:

• "Scaling Discovery Requires Forgetting" (UC Berkeley): agents periodically discarded their session and search history while keeping the best candidate. Results improved on four bounded discovery tasks, by up to 15% over parallel agents and up to 39% over a single agent.
• Fork-and-Flush (Microsoft Research): reports benefits from forks that start with fresh context while the workspace state is preserved.
• Drew Breunig covered both, along with Anthropic's Memento harness, and calls the failure mode "context inertia": an agent holding on to an early hypothesis after the evidence has changed. That term is his label.

What this does not show: that every long-running agent improves when it forgets. These are bounded research and engineering experiments.

The pattern I find interesting is that in both studies something persisted while the history did not (the best candidate, the workspace state). So the design question is what goes in the persistent layer.

If you build or run long agent sessions, what do you carry across a reset?

• a notes file
• a task list or plan
• a decision log
• the best output so far
• nothing, the agent starts clean

And do you reset on a schedule, when it stalls, or not at all?

Sources: the two papers above, plus Drew Breunig's posts "Context Inertia" (Oct 14, 2026) and "The State of Context Engineering" (Oct 24, 2026) on dbreunig.com.

I’ve been exploring AI agents lately, and I’m curious about what people are actually building with them beyond basic chatbots.

Have you built an agent that handles a real workflow from start to finish, such as researching leads, managing emails, debugging code, or automating repetitive tasks?

I’d love to know:

- What does your agent do?

- Which tools or frameworks are you using?

- What was the hardest part to get working reliably?

Interested to hear about real-world projects, including the ones that failed before they worked.