Engineering v. Architecture
When we Architect the process, we push the engine beyond the expectations of the factory.
Systems are engineered. Thinking must be Architected.
For the past quarter, I have used the term "Context Engineering" to describe the work of optimising AI inputs.
I am formally deprecating that term today.
Words carry weight. "Engineering" implies the wrong domain. It suggests the value lies in the code, the syntax, or the "backend" optimisation of the pipe. It treats the AI as a machine to be fixed.
That is vital work. None of us would be able to wield this technology without the engineers who build the seamless backends we rely on.
But my work—and the work of any leader using this technology—is not about how the machine works. It is about how the human thinks. It is about pedagogy.
Therefore, I am shifting the protocol to "Context Architecture."
The difference is operational:
- The Engineer (The Builder): Focuses on "making the machine run." They optimise for latency, function, and error reduction.
- The Architect (The Strategist): Focuses on "steering the intent." We design the Evidence Scaffold and the Workflow Layer to ensure the output aligns with human reasoning.
If you bought a Ferrari, you wouldn't dream of opening the bonnet to re-wire the V12. You might understand the theory of combustion, but you respect the craftsmanship enough not to touch it.
The Engineer has given us an incredible engine. Let's not insult them by pretending we can do their job. Our job is to take that machine and drive it in ways the builders never anticipated.
When we design the engagement—when we Architect the process—we push the engine beyond the expectations of the factory.
This is not an abdication of responsibility; it is a delineation of expertise. I refuse to appropriate the language of the Engineer to explain the work of the Pilot. It confuses users and alienates the very people crafting the technology we use.
Stop messing with the engine. Learn to drive the car.
