u/Financial_Ad_7297

I've been rethinking how we report organic visibility in 2026.

Traditionally, it was pretty straightforward:

rankings → impressions → clicks → conversions.

But with AI Overviews and AI Mode, I'm seeing a different pattern. A page can rank well and still contribute to an AI-generated answer without getting the click.

At the same time, a brand can show up in an AI answer or get cited even when its traditional search ranking isn't particularly strong.

So how are people actually handling this in reporting?

Are you tracking traditional rankings alongside AI Overview appearances, AI Mode citations, brand mentions, competitor visibility, and AI referral traffic?

Or is AI visibility still mostly an experimental metric for your clients?

I'd especially like to hear from agencies. What are clients actually asking you to report on in 2026?

There are some consulting deliverables that used to take a decent amount of analyst time but can now be produced surprisingly quickly with AI.

A first pass of market research, competitor analysis, meeting notes, benchmarking, or a basic set of slides can be generated in a fraction of the time it used to take.

That raises a question I've been thinking about: if the actual production of the deliverable becomes much cheaper, what is the client really paying for?

The analysis and judgment behind it? Knowing what questions to ask? Being able to defend the recommendation with the client?

Where do you think the value shifts when AI can handle most of the first draft?

I've seen people have pretty different experiences with LangChain.

Some teams build around it and seem perfectly happy with it. Others start with it and eventually replace parts of it with their own code or move to something else.

I'm interested in what actually drove that decision.

Was there a point where LangChain started getting in the way, or did you just realize the application didn't need that much abstraction in the first place?

And for people who stuck with it, what made you decide it was still worth keeping?

What was the biggest factor in your decision?

I've been seeing a lot of systems described as "agents" where the basic flow is still pretty predictable.

The model gets some context, chooses one of a handful of tools, gets the result, and moves on to the next step.

That can still be useful. But at some point I start wondering what actually makes it an agent rather than an LLM sitting inside a workflow engine.

Does the model need to decide what steps to take? Does it need to be able to change its plan halfway through? Or is tool selection and a bit of reasoning already enough?

I don't think there's a single correct definition here, but the distinction matters when you're designing these systems.

Where would you draw the line?

I've been wondering about this after seeing how much AI work has picked up over the last year.

Has it changed the mix of people getting pulled into projects?

From the outside, it seems like AI projects would create demand for a whole new set of skills. At the same time, a lot of the work still depends on things like engineering, cloud, data, architecture, and understanding the client's business.

For people who are actually on these engagements, was there anything about the staffing mix that surprised you?

A lot of AI projects get judged early on by whether the model works and whether the use case makes sense.

But what I'm interested in is everything that comes after that. For those who've worked on enterprise AI engagements, what seemed relatively minor at the beginning but ended up taking far more effort than expected later on?

I've noticed that some of the biggest challenges aren't always the ones people spend the most time talking about at the start of a project. Things can look straightforward during a pilot and then become much more complicated once the solution has to fit into existing processes, systems, and ways of working.

When you look back at projects you've been involved with, what was the issue that grew in importance as the project matured?

I've noticed a pattern in a few projects I've worked on.

A workflow starts out with one agent. Then it gets split into a planner, a researcher, and a few other specialized agents because the architecture seems cleaner that way.

Sometimes it helps. But other times it just creates more handoffs, more things to debug, more latency, and more opportunities for something to go wrong.

A couple of times, I've seen a workflow get simpler and more reliable after moving back toward a single agent with clearer instructions and better tooling.

I'm not against multi-agent systems. There are definitely cases where they make sense.

But I sometimes wonder whether they're being introduced too early, before anyone has proven that the problem actually needs them.

Has anyone else gone through that process and ended up simplifying an agent architecture instead of making it more complex?

When I first started building LLM applications, most of the effort seemed to go into prompts.

A lot of the discussion was about wording, structure, system instructions, and getting more consistent outputs from the model.

These days, I find myself spending much more time thinking about memory.

The hard part isn't storing information. It's deciding what deserves to stick around, when it should be updated, and how much of it should be brought back into future interactions.

I've seen agents become dramatically more useful once memory was handled properly. I've also seen memory make things worse because old context kept showing up long after it stopped being relevant.

For people building agents, where are you spending more effort these days?

Are prompts still the bigger challenge, or has memory become the thing that's harder to get right?

I've found that the model itself usually isn't what gives me the most trouble.

The problems tend to show up in the parts around it.

A prompt change fixes one set of queries and unexpectedly hurts another. Retrieval looks better when you inspect the documents but somehow produces worse answers. A tool works perfectly on its own until the model has to decide when to call it. Then there are all the issues that only appear after real users start interacting with the system.

Traditional testing doesn't always fit neatly here either. You can have everything passing and still end up with behavior you didn't expect.

For those building LLM applications, what's been the hardest thing to test reliably?

And what kinds of failures keep finding their way through even when you think you've covered everything?

I've been thinking about permissions a lot more as agents start doing things instead of just giving answers.

An agent might have access to a database, an internal API, email, a browser, or some other system. Giving it access is easy enough. The harder question is figuring out what that access should actually look like.

Should an agent have its own identity? Should it inherit the user's permissions? Should access to certain tools only last for one task? And what happens when the agent needs to do something sensitive that normally requires a person to approve it?

The audit side gets interesting too. If an agent changes a customer record or sends an email on someone's behalf, I want to know exactly which user authorized it, which agent actually performed it, and what happened along the way.

I'm wondering how teams are handling this in production.

If an agent takes an action on behalf of a user, who should that action ultimately be attributed to?

I've been seeing more AI implementation work coming out of APAC over the past year, and I was wondering if teams are starting to converge on the same reusable building blocks.

After the first few client engagements, it doesn't make much sense to rebuild everything from scratch. Most teams seem to end up with some mix of templates, evaluation workflows, governance checklists, deployment patterns, or internal tooling that gets reused across projects.

For those working in the Big 4 across APAC, what's been the most valuable accelerator your team has built or adopted?

Not looking for anything proprietary. I'm more interested in the kinds of assets that ended up saving time across multiple engagements.

I've been wondering how much GenAI work inside Accenture has changed over the past year.

From the outside, it seems like the conversation has shifted quite a bit across the company. There seems to be less excitement around quick demos and a lot more focus on getting things into production.

For those working on these projects, has your day-to-day changed much?

Are clients asking for different things now than they were a year ago, or does it still depend mostly on the account, industry, or region?

I'd be interested to hear what trends people across Accenture have been seeing.

Say someone has already built a few LangChain demos and is about to build their first production application.

Knowing what you know now, what's the first piece of advice you'd give them?

Could be about retrieval, memory, agents, state management, evaluation, observability, deployment, costs, or something completely different.

What's one lesson you only learned after running a real LangChain application instead of a demo?

A lot of agent projects seem to follow the same path. Start with a basic workflow, then keep adding tools, context, and more decisions the agent can make on its own.

I'm not sure more autonomy always makes the agent better.

For most real workflows, I'd rather have an agent handle the routine stuff reliably and know when to hand something off. Once it can send emails, change records, trigger workflows, or talk directly to customers, letting it figure out every unusual case on its own creates a lot more room for things to go wrong.

Maybe autonomy isn't the best measure of how capable an agent is.

How often someone has to step in and correct it might tell you a lot more.

I've noticed that different teams seem to judge AI customer support systems in completely different ways.

Some care about deflection rate. Others look at average handling time, first response time, CSAT, first contact resolution, or simply how much support costs have come down.

The problem is that improving one metric doesn't always mean the overall experience is better. An assistant might deflect more tickets, but if people keep reopening them or immediately ask for a human, that number doesn't say much on its own.

If you could only track one or two KPIs to judge whether an AI support system was actually doing its job, what would you choose?

I'd be interested to know whether your answer changes depending on the type of support team or industry.

Debugging LangGraph workflows has been a lot less straightforward than I expected.

When the final output is wrong, the actual issue usually isn't where I first look. It could be retrieval, a slow or failing tool, an unexpected branch, or state changing somewhere earlier in the graph.

By the time you notice something's off, the root cause can be several steps back.

For those running LangGraph in production, what's your usual starting point when you're debugging?

Do you look at execution traces, tool calls, token usage, or something else that's consistently helped you narrow things down?

Something I didn't expect from all this agent work is how often I stop thinking about the human using the software.

A lot of the interfaces being built now aren't really meant for people. They're meant for agents.

Instead of clicking through dashboards, the agent calls an API. Instead of reading a paragraph, it gets structured data. Instead of navigating a UI, it works with tool schemas and permissions.

And that got me wondering if we're heading toward a world where a lot of business software is designed with agents as the primary user and humans as the supervisors.

If that happens, I wonder how much software design changes. Do dashboards become less important than APIs? Do we spend more time designing reliable tool interfaces than polished UIs?

Am curious whether other people have started thinking about this too, or if I'm reading too much into where things are heading.

Most conversations about building agents seem to revolve around models, prompts, RAG, memory and tool calling.

Then you try to get one running reliably outside of a local setup and suddenly you're dealing with retries, queues, permissions, logging, rate limits, tracing, rollbacks and a bunch of other stuff you barely thought about when you started.

For anyone who's actually put agents into production, what ended up being the infrastructure problem you underestimated the most?

Also, did you find decent tooling for it, or did you eventually give up and build something yourself?