#57 - On Context Engineering
What Is Context Engineering, and How It Can Drive AI Adoption
Overview
I won't explain the term Context Engineering, but I do want to share my take on it, what it relates to, and some concrete examples from the engineering space.
Context gaps
As a B2B prospect, when I look for software, I usually search online. I have a pattern to find the software I think I need or want. I go to its website, see some use cases, and if I'm interested, I raise my hand and wait to be contacted.
At this point, there are some assumptions that only I know about:
Why I think I need this software.
What are the problems that I believe I have that this software might help me with?
What is the value I perceive from this software that might solve these pain points?
On the other hand, there's someone from a GTM team, for example, an SDR, seeing my hand raised, doing a bit of a discovery, and now he's trying to assess additional points -
What he believes I'm looking for.
What he assumes are my pain points.
What is the possible value I might get from the product?
How to start the sales process?
The different realities
If we were to meet at this point, we'd have a lot of hidden context:
What I think my pain points are.
What I think this product could help me with.
What the salesperson believes my perception of the product would be.
What the salesperson is trained on is the value of the product.
What are my true pain points?
If we had the discussion today, it would be very difficult to bridge this gap. There are all kinds of different realities that we couldn't talk about - some are hidden, and some are between the lines. It would be very hard to get alignment and action items from such a call.
This doesn't say these calls don't happen. But the usual sales process is:
A B2B prospect comes in, wanting to see a real demo and get the price.
The salesperson arrives, asks a bunch of questions for 10 minutes, shows a couple of slides for an additional 5 minutes, and asks for a follow-up meeting where maybe they'll see a demo.
Ideal context situation
Let's consider a different possibility. As a prospect, I know exactly what my pain points are and am very aligned with what I need. When I see the product, the value propositions are very clear.
The site is great, the messaging is on point, and I have a live demo. I even signed up, tried it for myself, and verified it can solve my pain points.
The salesperson on the other end has access to my usage data. He has wide and deep knowledge of the industry and where I specifically come from, so he can actually tailor what the product can do for me if I use it more extensively.
Now, at this point, if we meet, the chance we'll get aligned is very high. And a possible discussion would just be to go over a slide or two, make sure we fully understand the picture, discuss next steps, and possibly pricing.
In a way, if I already use the product, and I get it, I love it, I want to buy it, I don't need to see ten slides explaining the history of the company. I just don't.
Transition to Engineering
Let's switch the record and move the example to the engineering side.
Let's imagine I go into one of the generative AI products and just write something like:
Provide the code to fix issue ACME-123.
Obviously, the expected response would be:
I'm happy to help you, but what is ACME-123?
It's not that far from a salesperson, where a prospect comes in asking for a demo. The salesperson is asking, “What are we demoing for?”
Opening a blank GPT chat is like working without context.
Context engineering is how you add your unique context that the LLM is not trained on. It starts with simple prompts and instructions, followed by extensive data access so the generative AI gets the wider picture and eventually achieves higher accuracy with fewer attempts and words.
Context engineering examples
I want to share some real-world examples to make it concrete.
Service ownership
Understanding the owner of a specific service so we can inquire about it and possibly contribute to it. The prompt would be:
Who owns the service checkout in our company?
Context engineering needed:
Software catalog.
Team structures and their members.
Organizational structure.
The commit history of each service.
Service README file.
Recent Jira tickets per service.
Skill sets of engineers, especially those familiar with frameworks relevant to the service.
Critical incidents
Understanding the production situation in regard to incidents. The prompt would be:
What are the critical incidents we currently have?
Context engineering needed:
Identification of who “we” refers to (team, company, or specific user).
Understanding system and service dependencies.
Awareness of historical prompts and queries from the user to infer intent.
Access to incident data.
Incident priority levels.
Mapping of incidents to related services.
Identification of which services are considered critical.
Information on which customers are impacted by current incidents.
Next tasks for today
Helping a developer quickly understand what they should focus on. The prompt would be:
What are my next tasks for today?
Context engineering needed:
Current workload and task list.
Incident tickets assigned to the developer.
Jira tickets assigned to the developer.
GitHub issues opened in public repositories they own or contribute to.
Support tickets awaiting the team’s response.
Overdue on-call action items.
Open security issues nearing their SLA deadlines.
Developer’s daily calendar.
Pull requests to merge or review.
Prioritization context - company-wide priorities, strategic projects in progress, and teams the developer is part of.
Provisioning cloud resources
In daily work, a developer may need to provision resources (e.g., a new Kubernetes namespace or a new database). The prompt would be:
For task ACME-123, I need to create a new S3 bucket. How should I go about it?
Context engineering needed:
The task context (description, priority, links).
Organizational conventions (naming, tagging, environments).
Who is allowed to provision it, and what is the permission model?
Required approvals and the approver(s).
The standard process for this resource in the organization.
If using direct integrations: the API or step-by-step walkthrough.
If using Infrastructure as Code: how to author the Terraform file, where it should live, and who should approve the PR.
Conclusions
Context engineering is about making LLMs more useful by giving them the right context to understand where developers are coming from and the ecosystem they operate in.
The challenge lies in providing high-quality context without over-exposing tools or data in ways that create chaos and erode trust, ultimately reducing AI adoption. To me, the concept is clear, but its execution is the true hurdle.