Jacob Dietle is a context engineer who runs a solo consultancy for venture-backed companies. Jacob studied information systems in college and after working at a few startups, decided to found his own agency. After spending time doing custom dataset build-outs, the agency ultimately focused on go-to-market engineering work, building automations and AI workflows for clients. The more Jacob used AI on that work, the clearer it became to him that the bottleneck on AI’s capabilities was its context. That realization became the focus of his consultancy, and now Jacob helps companies build context engines to maximize AI’s impact across their highest value go-to-market use cases.
In this podcast, we discuss:
How Jacob thinks about context and the effect it has on AI output
How Jacob built a system that cut a client’s newsletter creation process from 6 hours to 30 minutes
Why Jacob keeps a person in the loop to validate AI output
How to build a strong foundation for a context engine
How to split context work between off the shelf tools and building yourself
Why Jacob suggests building and managing context the way an engineering team ships code
Episode highlights:
Context is vital because it gives AI the background it needs to produce specific, relevant output for a company instead of falling to the lowest common denominator of quality.
Jacob helped an application security company’s head of GTM speed up their newsletter creation process. He built a reading list that pulls from the high-signal people in the AppSec space, generates a brief from them, and drops the briefs into a repo that Claude Code can use as context when taking a first pass at the newsletter. The result cut the newsletter writing process from roughly six hours to 30 minutes.
While AI can be extremely helpful and sometimes produce better work than a person would, because it doesn’t reason like a person, a single missing piece of context can throw it off completely. That’s why Jacob always keeps a human in the loop to validate the output, and why he sees AI as best used to amplify an expert rather than to replace one.
Jacob recommends starting a context engine with just a few use cases, because working through them surfaces the context bottlenecks that will hold the system back as it scales. Working through an early use case like sales transcript analysis quickly reveals key context, like an ICP definition, that AI needs before it can produce anything useful.
On build vs. buy for your context OS, Jacob’s answer is to do both. Octave and tools like it give you a go-to-market context graph out of the box with integrations ready to go, which is what you want when a whole team needs to use it for a specific use case like email drafting. However, building your own context engine is also worth it for the customization it affords, like the newsletter example. Building also gives a deeper understanding of how context works, which helps teams make the tools they buy more powerful.
Jacob suggests managing context the way an engineering team ships code. The whole system is versioned in one place, so everyone can draw from it when adding context to their workflows, changes are easy to track over time, and teams can collaborate on adding to it. Updates to context can get proposed, reviewed, and merged in. Since the AI handles the technical overhead, the bar to ship is low enough to let non-technical teammates contribute to context building, too.
Where to find Jacob:
taste.systems (his consultancy)
Transcript details:
(00:00) Intro
(07:19) Defining context in AI
(09:16) The newsletter context system that Jacob built
(12:59) Human in the loop and pitfalls
(14:43) The foundational pieces to get right when building a context engine
(16:21) Finding the bottlenecks in your context system and back pressure testing
(20:53) How to decide when AI is good enough to handle a task and its worth building context around
(25:35) Technical setup nuances when building your context OS
(30:44) Build vs buy with your context OS
(39:20) How to effectively enable multiplayer mode with your context OS
(45:05) Ownership and staffing this system internally
(46:49) What it’s been like learning about a completely new field and building tastematter.dev
(52:33) Underrated tool, favorite growth hack, and wrap up
This episode of the gtm engineer is brought to you by Dust
Most AI agent tools are built for individuals. Dust is built for teams. Dust puts AI agent building on multiplayer mode and connects to your company’s knowledge across platforms like Slack, Google Drive, Notion, GitHub, Salesforce, and Snowflake.
Anyone can build agents that draw on that knowledge to handle tasks like researching accounts, answering customer questions, or drafting prospect emails. Dust also gives ops and IT the governance controls (permissions, SSO/SCIM, audit logs, role-based access) they actually need to confidently roll something like this out across an org.
The agent builder itself is no-code, so anyone with a Dust seat can prototype an agent in an afternoon without ever opening Terminal. With the whole company on the same platform, you get visibility into who’s building what and what’s being used the most.
If you want to check them out, you can use code “THEGTMENG” for your first month free
For inquiries about sponsoring the podcast and to recommend any guests, email noah@thegtmengineer.ai
