Technical communication has always been a field that lives at the intersection of systems and people. We do not just explain technology. We analyze situations, structure information, design workflows, and evaluate whether communication actually works for the people who use it.
That is why context engineering is suddenly such an important term for our field.
The phrase itself was coined by Andrej Karpathy, who defines it as “the delicate art and science of filling the context window with just the right information for the next step.” Abram Anders deserves real credit for bringing the term into technical communication through his keynote, “Co-designing Agentic Futures: Context Engineering as Technical Communication Expertise,” at the AI in Technical Communication 2026 symposium, and then extending the argument in a recent post on his Substack.
What Anders makes clear is that context engineering is not some alien concept imported from computer science. It is a way of naming work technical communicators have been doing for decades.
What Context Engineering Actually Is
At a basic level, context engineering means designing the informational, procedural, and rhetorical environment in which an AI system operates. It is not just writing a good prompt. It is deciding what information should be available, what sequence of actions should happen next, what human oversight is needed, and how the system should behave within a specific social and organizational setting. This follows directly from Karpathy’s definition and from Anders’s argument that the real issue is not isolated prompting but designing the conditions for the next step in a workflow.
That is why context engineering matters more now than it did even a year ago. Early generative AI was mostly about chat. You asked a question, it gave a response, and you decided what to do with it. But Anders points out that agentic AI changes the problem. Agents can write files, send emails, make appointments, and trigger workflows. Once that happens, designing context becomes a mainstream design challenge rather than a niche engineering problem.
Why Context Engineering Is Useful
The most useful part of Anders’s argument is that it explains why AI capability and AI use are not the same thing. He notes that AI can often do more in theory than people actually let it do in practice. The reason is not simply slow adoption. It is that technical capability is different from social authority. A system may be able to perform a task, but that does not mean people want it in charge of that task inside a real workplace or community.
This is where context engineering becomes useful. It helps us think about how AI should be integrated into human systems rather than imagining that technical capability alone will determine adoption. It shifts attention from what the tool can do to how people actually want to work with it. Anders reinforces this point with worker preference data showing that most people prefer equal partnership with AI, not total automation.
That should sound very familiar to technical communicators. We have spent years studying exactly this type of problem. How do people use systems in context? How do they interpret information? What kinds of communication make action possible? What kinds create confusion, mistrust, or resistance?
Context engineering is useful because it gives us language for that work in an AI environment.
Why This Is Already Technical Communication Work
One of the strongest parts of Anders’s keynote is his claim that context engineering is rhetoric. He argues that communicators already curate what information is relevant to a given audience, purpose, and moment. We already structure workflows so that analysis precedes ideation. We already evaluate outputs with real users to see whether they achieve the intended purpose. In his words, every part of what Karpathy describes maps directly onto technical and professional communication as a discipline.
I think that is exactly right.
When we do audience analysis, we are doing context engineering. When we build content systems, we are doing context engineering. When we design human-in-the-loop review processes, we are doing context engineering. When we conduct usability studies to see whether a communication artifact actually works in practice, we are doing context engineering.
The field has not always used that phrase. But the work is deeply familiar.
Why Context Engineering Matters for the Future of the Field
What makes this more than a useful label is that it points to where the field can go next.
Anders argues that the most productive research space is not simply asking whether AI should be used or resisted. It is designing human-AI collaboration patterns for tasks that require human judgment, rhetorical sensitivity, and contextual awareness. He points to workflow studies, cognitive and metacognitive load research, trace-data research, and co-designed tools for specific communities as especially promising directions.
That is a compelling agenda for technical communication because it treats our field as central rather than peripheral. It suggests that the future of AI in professional settings will depend less on raw model capability and more on whether someone can design systems that keep human expertise, organizational trust, and audience needs in view.
That is exactly the kind of work technical communicators are trained to do.
Context Engineering and the Shift Beyond Prompt Engineering
For the last few years, a lot of conversation has centered on prompt engineering. That made sense for an earlier phase of generative AI, when most interactions happened through one-off chat exchanges.
But prompt engineering was always too narrow to describe the full communication problem. Context engineering is a better concept because it recognizes that useful AI depends on more than a single query. It depends on workflow design, information architecture, genre expectations, user goals, institutional constraints, and ongoing human judgment.
In other words, it depends on context.
That shift matters for technical communication because it re-centers the parts of communication work that are hardest to automate. Not the production of fluent sentences, but the design of systems in which language, action, and human decision-making actually align.
Why Technical Communicators Should Pay Attention Now
Technical communication should pay attention to context engineering for a simple reason. If AI systems are going to be embedded into workplaces, classrooms, nonprofits, government offices, and community infrastructures, then someone has to decide how those systems are framed, constrained, documented, evaluated, and revised.
That is not just a technical problem. It is a communication problem.
Karpathy gave us the term. Abram Anders brought it into our field and made the case that it describes a core area of technical communication expertise. The next step is for the rest of us to take that idea seriously.
If context engineering is the work of designing the right information for the next step, then technical communication is already one of the disciplines best equipped to do it.