u/Meher_Nolan

Genuine question because I'm trying to understand what people are actually paying for here.

I've looked at quite a few GEO/AEO agencies, and the service descriptions tend to sound pretty similar: improve AI visibility, increase citations, build entity authority, optimize for LLMs, etc.

But what does that actually look like once you're paying the monthly retainer?

Are they rewriting existing pages, creating new content, building third-party mentions, doing digital PR, running large prompt sets, analyzing competitor citations, targeting specific discussions, or monitoring how AI answers change over time?

Or is a big part of the engagement still running prompts, tracking visibility, and putting together a report?

I'm particularly interested in what happens between the monthly reports. What are they actually changing or executing based on what the data shows?

If you've hired a GEO/AEO agency, what does the work actually look like month to month? And if you've been doing it for a while, what changed between the first few months and where you are now?

I've been looking at a bunch of AI visibility and GEO platforms lately, and I'm starting to wonder if we're creating another SEO metric that looks useful without necessarily telling us much.

A dashboard might tell you:

Brand visibility: 64%
Competitor A: 71%
Competitor B: 48%

But what does that 64% actually mean for the business?

If most of those appearances are coming from informational prompts with no buying intent, I'm not sure there's much value in the number by itself.

The same goes for improving from 40% to 70%. If that increase doesn't translate into better recommendations, qualified traffic, leads, or even more branded searches, did visibility actually improve in a meaningful way?

I've been running some of this through wintraction, and one thing that's stood out is how different the picture can look once you break the visibility down by the type of prompt instead of looking at one overall percentage.

I'm starting to think AI visibility needs to be tied to the context behind the prompt. A brand showing up for a high-intent recommendation is probably worth more than showing up across dozens of generic queries.

So maybe the useful question isn't simply “How often is the brand mentioned?”, but “Where is it being mentioned, how is it being recommended, and does that visibility lead to anything?”

How are people actually measuring this? Are AI visibility scores useful enough to guide decisions, or are we heading toward another DA/DR-style metric that everyone tracks but nobody really knows what to do with?

Naake kanipinchatledha ledha akkada bookings ae leva. Also I saw a post in vizag sub where the op said that they watched Avengers in s-5 on Saturday but I don't remember any movie being played there other than paradise at that time. What is even happening with these bookings? Awful.

With most software projects, the repo is usually the source of truth. With agents, half the logic is scattered across prompts, configs, framework abstractions, tool wiring, and memory setups. Also, portability barely exists. Things break in absurd ways when the framework shifts. Even prompts don't transfer cleanly between models sometimes. Feels like the ecosystem still hasn't figured out a clean way to structure and version this stuff yet.

Are people just living with the mess right now or have you found workflows that actually scale?

I've been seeing long-term memory, conversation history, vector retrieval, user profiles and similar stuff added to agents almost by default.

But for a lot of workflows, I'm not sure how much of that is actually needed. Sometimes the agent probably just needs the current state, what happened earlier in the task, and a few relevant facts.

I’m starting to think some of what we call “agent memory” is really just state management with better marketing.

Where have you actually found persistent memory to be useful in production, rather than just something that seemed like a good feature to add?

AI is already taking on a lot of the work that used to fill up junior consultants' time. Research, documentation, code and increasingly parts of the actual delivery.

A lot of junior experience comes from doing the less glamorous work first. Pulling together information, cleaning data, putting together first drafts, fixing slides, documenting things, and stitching together work from different teams.

But AI can already handle several parts of that.

I keep wondering if we'll eventually have smaller teams with AI doing a much bigger share of the execution, instead of just making the existing teams 20% faster.

If some of that junior-level work disappears, what does the learning curve look like for people entering consulting?

For people in consulting, are you actually seeing AI change staffing and delivery yet, or is it still mostly a productivity layer on top of the existing pyramid?

One thing I've been wondering about is where people draw the line between agent orchestration and application architecture.

LangGraph handles a lot of things that show up in real systems: state, branching workflows, retries, human approval, multi-agent patterns, long-running tasks, and so on.

But once a system grows, you also end up thinking about persistence, observability, recovery, model fallbacks, permissions, and all the other operational concerns that come with running something in production.

At some point, it stops feeling like "an agent workflow" and starts feeling like a distributed application that happens to contain agents.

For people who've pushed LangChain or LangGraph pretty far, where's that boundary for you?

When does the framework continue to help, and when does it start becoming another layer you have to work around?

A lot of agent workflows are designed around what should happen when everything works.

The agent gets a request, calls the right tool, gets a useful result, and finishes the task.

Production obviously doesn't stay that clean.

A tool can return incomplete data. An API can time out. The agent can make the wrong decision halfway through a task. A retry can produce a different result. Sometimes the workflow just gets stuck and needs to stop rather than keep trying.

I've started paying more attention to what happens after things go wrong than what happens when everything goes according to plan.

A production agent needs some idea of when to retry, when to change approach, when to ask for help, and when to give up cleanly.

How are you designing recovery into agent workflows?

A lot of agent demos make the reasoning look like the difficult part.

Once the workflow has to run through several steps, though, I've found that keeping track of what's happening can become just as difficult.

The agent needs to know what it already tried, which tool results are still relevant, what decisions have already been made, and what information should carry into the next step. Things get even messier when a task pauses, fails halfway through, or gets picked up again later.

A capable model doesn't help much if the state around it isn't handled properly.

I've started thinking about agent architecture as more than just a model connected to a set of tools. The state, constraints, and recovery behavior can end up determining whether the whole thing is reliable.

For people building agents that run across multiple steps or sessions, how are you handling state?

So I just got into Iki Island and randomly stumbled upon a hostage scene immediately. I lost the fight tho. The mongols beat my ass up, khunbish knocked me out and now the " eagle confrontation" cutscene has triggered. Had to quit the game at the cutscene cause I had some work to do. Maybe I can continue the game as usual after the cutscene but it just got me feeling like I've skipped a whole part of the game and went straight to the middle😭😭

One thing I think gets overlooked when making architecture decisions is how difficult the decision will be to undo later.

Some choices are easy enough to change once you have more information while others can become deeply embedded in the system, the team's processes, and the surrounding infrastructure before anyone realizes how expensive they are to replace.

I've run into this with things that seemed perfectly reasonable at the time. The problem usually wasn't that the original decision was obviously wrong. It was that changing it later affected far more of the system than expected.

I've been thinking about this more with AI systems as well, since models, tooling, and agent architectures are changing pretty quickly.

What's an architectural decision you've had to reverse that turned out to be much harder than you expected?

It seems like every few months there's a new technology that suddenly shows up in client conversations because someone senior has seen it somewhere.

AI agents are probably the obvious one right now, but I'm sure the same thing has happened with plenty of other technologies over the years.

Sometimes the request makes sense. Other times the technology gets picked before anyone has really worked out what problem it's supposed to solve.

For those working in the Big 4, what's one of these requests you've come across?

What did the conversation look like once you actually had to work out whether it made sense for the client?

It seems like getting an AI proof of concept built has become much easier over the past couple of years.

What I'm less clear on is what happens after that.

For those who've worked on AI engagements, what's usually the biggest obstacle between a successful PoC and something that's actually deployed and used at scale?

I hear a lot about successful pilots, but far fewer stories about what prevented the next step from happening.

When you've seen projects stall, what was usually the underlying reason?

I've been wondering about this lately because the AI conversations I see now seem pretty different from the ones I was seeing a year ago.

Back then, a lot of the attention seemed to be on pilots, demos, and figuring out where AI could fit. Now it sounds like more organizations have moved past the "can it work?" stage and are dealing with the realities of rolling it out.

For those working on client engagements, has the nature of the work changed much?

Are clients showing up with clearer expectations now, or are teams still spending a lot of time helping them figure out where AI fits in the first place?

I'd be interested to hear what shifts you've noticed from the projects you've worked on.

A lot of teams are getting pretty far into building agents now, and I keep wondering how many of them could actually move those systems somewhere else if they had to.

It's easy to ignore early on. You pick a framework, wire up some tools, add memory, connect a model provider, and keep shipping.

The question gets more interesting later.

What happens when another team uses a different stack? What happens when you want to switch providers, move clouds, or standardize across multiple projects that were built independently?

We've seen similar problems before in other parts of software. Things work fine until they need to move.

I'm wondering whether agent ecosystems eventually converge on common standards, or whether we're heading toward a future where moving an agent between platforms is a bigger project than most people expect.

I've been looking at a lot of agent benchmarks lately, and I keep running into the same problem.

A benchmark can tell me that one system scored better than another on a particular task, but it doesn't tell me much about what it's like to run that system in the real world.

The questions I end up caring about are usually operational. What happens when something goes wrong? How often does a human have to step in? Is it easy to understand why the agent made a decision? Does it stay reliable once it's been running for weeks instead of hours?

I've seen agents that weren't benchmark leaders but were far easier to trust because their behavior was predictable and easier to operate.

Maybe that's why I find benchmark results less useful than I used to.

When you're evaluating agents, what signals matter most to you?

I've noticed that a lot of AI products don't stay in the category they started in.

Something launches as a tool, does one thing well, and that's the whole value proposition. Then a year later people are connecting it to other systems, building workflows around it, sharing it across teams, writing integrations for it, and depending on it for things it wasn't originally designed to do.

Looking at some of the bigger AI products today, I'm not even sure "tool" is the right word anymore.

The interesting part is that there never seems to be a clear moment where the transition happens.

People don't wake up one day and decide they're using a platform now. It just gradually becomes part of how work gets done.

For those who've seen products make that jump, what was the signal?

What made you realize something had stopped being a tool and become a platform?