The Context Triangle

The current generation of models is already very good and getting better at a wild pace.

Not AGI but remarkably capable at the kinds of tasks we ask engineers to do every day: writing code, explaining systems, summarising discussions, proposing designs. When they fail, it’s increasingly not because they lack raw capability, but because they lack the right context.

In other words: the intelligence isn’t the bottleneck anymore. Context is.

From Prompt Engineering to Context Engineering

Early on, almost all context lived inside the prompt. You typed everything you thought the model needed to know, crossed your fingers, and hit enter.

That’s no longer how serious systems work.

Today, we see context coming from many places:

• Structured markdown files

• Steering documents

• Tool integrations and plugins

• Skill systems and agent frameworks

• Repositories, tickets, and design docs

Different ecosystems give these things different names, but under the hood they all do the same thing: select relevant information and inject it into the model’s context window before the prompt is executed.

That shift made me realise something:

instead of thinking about a single, monolithic “context”, it’s more useful to break context into distinct categories with different properties.

What follows is the mental model I’ve been trying on.

A Triangle of Contexts

I'm finding it useful to think in terms of three primary types of context:

1. Task Context

2. Organisational Context

3. Personal Context

Each behaves differently. Each should be filtered differently. And each can hurt performance if handled poorly.

Task Context: Everything Relevant Right Now

Task context is the most intuitive.

It’s the information that directly defines the thing you are trying to do at this moment.

Examples:

• A Jira ticket or GitHub issue

• The current prompt

• A project README or design doc

• A project roadmap or ADR record

• The repository or service you’re modifying

In a microservices environment, task context is often nicely scoped and you can usually assume that most of the task context is relevant, and it often makes sense to include it wholesale.

Task context is:

• Highly specific

• Short-lived

• Closely aligned with immediate intent

Because of that, it’s usually the least risky context to inject aggressively.

Organisational Context: How Work Gets Done Here

Organisational context becomes important when your software engineering goes multiplayer.

As teams and companies scale, “how we do things” starts to matter as much as what we do. This includes:

• Preferred frameworks and libraries

• Internal platforms built on top of open source

• Opinionated defaults (logging, metrics, RPC, auth)

• Architectural constraints and patterns

• Cultural norms around reviews, ownership, and quality

For example, many companies have a preferred gRPC client, logging library, or internal abstraction that encodes years of decisions. From the outside, these look like arbitrary constraints. From the inside, they are how velocity is maintained.

Injecting this context into AI systems is incredibly powerful but can also be dangerous if done naively.

Not all organisational context is relevant to every task. If someone is fixing a frontend styling issue, injecting detailed context about backend caching strategies or datastore choices is at best wasteful, and at worst actively harmful.

Two problems emerge when organisational context becomes bloated:

1. Token waste; you’re spending context budget on irrelevant information

2. Conflicting guidance; internal docs often disagree subtly or assume different scopes

This means organisational context needs selective retrieval, not bulk inclusion.

The larger the company, the more this matters.

Personal Context: The Engineer as an Append-Only Log

The one I've recently been thinking about the most is personal context.

By personal context, I mean everything that captures how you work and what you’ve done:

• Notes and documents you’ve written or read

• Meetings you’ve attended

• Pull requests you’ve authored or reviewed

• PR comments and Slack discussions

• Projects you’ve touched over time

I find it useful to think of personal context as an append-only log. It grows continuously, accumulates history, and encodes tacit knowledge that never quite makes it into formal documentation.

But unlike task context, personal context is never “all relevant”.

Filtering here is critical and highly task-dependent.

Two axes matter most:

• Relevancy: which parts relate to the current task?

• Recency: how far back should we look?

Compare these two tasks:

• “Write my promotion document based on the past two years of work”

• “Help me implement this ticket in a service I touched last week”

Same person. Same underlying data. Completely different context selection.

Personal context needs dynamic, intent-aware filtering. Static rules won’t cut it.

Why This Matters

As models improve, differences in output quality increasingly come down to context quality, not model choice.

The organisations and teams that win won’t be the ones with the best prompts, but the ones that:

• Model context explicitly

• Separate different kinds of context

• Retrieve selectively and intentionally

• Accept that more context is not always better

If we get context right I believe we'll see tremendous boost in both quality and velocity in a very short amount of time and without the need for big leaps in the model capabilities.

Or maybe they'll just be big, cheap and smart enough that we won't need to bother

This was originally published on X. Crossposting here for a different audience