Your AI is only as good as the context you give it

This insight shared by Neil Berry, Service Delivery DXP France, UK & Nordics

AI adoption stalls when teams invest in prompts instead of context

The structured knowledge that turns generic output into something genuinely useful, regardless of the function.

The wall every team hits

Most teams adopt AI in the same way, regardless of function. Someone introduces a tool — a coding assistant, a content generator, a research copilot. The first few interactions feel transformative. Then reality sets in. The output is generic. Technically competent, but it doesn’t sound like the brand. It doesn’t follow the team’s conventions. It doesn’t understand why things are done a certain way.

Someone rewrites the output. Someone corrects the approach. The AI becomes a first draft machine that creates more editing work than it saves.

The typical response is to write more detailed prompts. Add more instructions. Be more specific about what you want each time.

That helps — but it doesn’t scale, and it’s different every time. Each person prompts differently. Each session starts from zero. The AI never learns how your organisation works because nobody has told it in a way it can remember. The output quality depends entirely on who’s asking, not on what the organisation knows.

The problem isn’t the AI. It’s the starting point.

Over the past year I’ve been working AI-first — and not just for engineering. Architecture specs, stakeholder communications, content strategy, team interviews, and presentation design. The same person, the same AI, but a different context loaded each time. The context is what shifts the output from generic to useful, not the person in the seat.

The pattern is the same everywhere. When AI has a prompt and nothing else, it guesses. Conventions, tone, architecture, brand voice, decision history — all guesses. Enough wrong guesses and the output needs reworking.

When AI has structured context, the guessing stops. The output matches how the team actually works. Not because the AI got smarter, but because it started from understanding rather than assumption.

A marketing team whose AI doesn’t know the brand voice gets generic copy. A legal team whose AI doesn’t know precedent and risk tolerance gets generic analysis. An engineering team whose AI doesn’t know the architecture gets generic code.

The function changes. The problem is identical.

The documentation you’re already doing, differently

Here’s the thing: organisations already invest heavily in documentation. Scoping. Requirements. Definition. Specifications. Discovery. It’s all documentation work — but it’s front-loaded, heavy, and done as a separate phase before any real work begins. By the time the documentation is complete, months have passed and the team’s understanding has deepened. There are processes to track that – but key learnings often surface after delivery is already underway, and accommodating them late means scope changes, rework, and costly adjustments.

In the delivery team I lead, we’ve taken a different approach. What we do is incremental. Documentation is the first step of every piece of work, not a phase that happens once at the beginning. We start with a problem statement, define the approach based on what’s already known, and the documentation evolves as decisions are made — not written up after the fact.

That said, more documentation isn’t automatically better. Recent research shows AI performance actually degrades when context is too large or unfocused — models lose track of what matters when it’s buried in noise. The investment isn’t in volume. It’s in the right knowledge, structured well. Conventions specific enough to follow. Decisions that include the reasoning.

Patterns that are current, not inherited from three architectures ago.

Each piece of work adds to what’s known. The architecture gets richer. The conventions get sharper. The decision history gets deeper. It’s taken time to get here, but the result is that any new piece of work — in any discipline — starts from the full accumulated knowledge of everything that came before.

It’s like placing the most experienced person in the seat every time. Not because the human knows everything — because the context does.

Why this compounds

This is where context infrastructure differs from most technology investments.

Each piece of knowledge you structure makes every future AI interaction better. Each convention you document is one less correction. Each decision you record with its rationale is one less wrong call — by a person or by AI.

The signal that it’s working: prompts get shorter over time. When someone can describe what they need in a sentence and the AI produces something usable, that’s not a better prompt. That’s richer context doing the work underneath.

New team members become effective faster because the knowledge infrastructure is already there. Handovers are cleaner. Institutional knowledge is more resilient. The same investment that makes AI useful also solves problems organisations have been struggling with long before AI arrived.

The traditional approach front-loads all of this into a discovery phase – and while there are mechanisms to adapt along the way, the structure makes it harder to absorb new understanding as it develops. The context-first approach builds it incrementally and absorbs learnings as they happen. Over time, the gap between the two widens.

Try this: open your AI tool of choice and ask it how your organisation works. What your team values. Why you do things the way you do. If the answer is generic — that’s the gap this article is about.

At JAKALA, we’re building AI-first delivery practices grounded in context infrastructure — applicable across engineering, content, strategy, and operations. If your teams have adopted AI tools but find the output still needs reworking, the answer is usually upstream of the prompt.

We’d welcome the conversation: get in touch to explore how a context-first approach could accelerate your AI adoption.