Go-to-market
engineer.

What this is and what it is for

Study guide. Track zero. How to use this guide.

This is the free route to becoming a go-to-market engineer, turned into material you can listen to. The plan itself tells you what to do and when. This guide is a different thing: it is for revising without a screen in front of you, while you drive, walk or wait.

There are eleven tracks. This one, nine tracks of one step each, and a final one for revision, with questions and answers.

Before we get to the first step, four things worth being clear about.

The accelerated calendar and the four questions

First. This is the accelerated version. The original plan spread one hundred and eighty-five hours across twenty-four weeks, at seven hours a week. This one packs the same hours into six hours a day: thirty-three working days, from Monday the twenty-first of September, two thousand and twenty-six, to Wednesday the fourth of November. Six and a half weeks instead of six months.

The content does not shrink. The calendar does. That has one consequence you should hear now rather than discover later: at this pace, nothing can slip. A lost day is not a lost hour, it is a lost six.

Second. Every step is studied with the same four questions, always in the same order. What you learn. Why it matters in your particular case. What you will be able to do that you cannot do today. And what the deliverable is, the thing that proves the step is closed. If at the end of a step you cannot answer all four, the step is not closed, however many videos you have watched.

Why this order and not a syllabus

Third. The nine steps are not in the order of a conventional syllabus. A syllabus would begin with programming. This route begins with vocabulary and then goes straight to evaluations, because your largest gap is not writing code: it is knowing whether what you have already built actually works.

Code arrives at step five, and only to read and debug it, never to write it from scratch. That decision is deliberate. You already have sixty scripts running. What you do not have is a way of proving they do what they claim.

What replaces the paid course

Fourth, and the most important. The free route replaces a paid cohort costing four thousand two hundred dollars. That cohort gave three things the free materials do not give on their own: a calendar with dates, feedback from an instructor on your own work, and peers to compare yourself against.

The route substitutes them like this. The calendar is the one in this plan, and it is kept. The feedback comes from Claude, but only on what you wrote first: your labels, your rubric, your judge, your query. Never written for you. And the comparison comes from your own scoreboard, which from day fourteen onwards tells you whether the agent improved or not.

One piece cannot be substituted by anything: the hour spent reading transcripts from your own agents. In the six-month version it was one hour every Friday. At six hours a day, it becomes the first hour of every single day. That is the only non-negotiable rule in the route. Without it, the free route stops being equivalent to the paid course and turns into a list of links.

The real cost

A note on money. The total cost of the route is zero dollars. The only small print: the graded laboratories at DeepLearning dot AI require a subscription. The videos, which is what the route actually uses, are free. Anthropic's certifications, at one hundred and twenty-five dollars, remain restricted to the partner network: apply, and do not count on them.

Right. Step one.

In one sentence

Step one. The map and the vocabulary. Days one and two, twelve hours.

In one sentence: giving what you already do the names the industry uses for it.

Workflow against agent

The first distinction, and the most useful, is between a workflow and an agent. A workflow is a fixed path: you decided the steps in advance and the model carries them out. An agent chooses its own next step, in a loop, until it finishes or runs out of budget.

Almost everything sold on the market as an agent is in fact a workflow. That is not a flaw: workflows are cheaper, more predictable and far easier to evaluate. Knowing which of the two you are building changes what it will cost you to run it.

The five design patterns

Then come the design patterns. Chaining, when the output of one model feeds the next. Routing, when a classifier sends each case down the path it belongs to. Parallelisation, when several independent runs are brought together at the end.

Orchestrator with workers, when a central model hands out subtasks and assembles the result. And evaluator with optimiser, when a second model criticises the first one's output and forces it to improve.

You already use four of those five without calling them by their names.

Tools, context and the harness

Then three ideas you will use every day. The first: a tool description is a prompt, not documentation. An agent that misuses a tool is almost always reading an ambiguous description, and the fix is not to scold the model but to rewrite the description.

The second: context engineering. Context is a budget, not a bag. The question is not what fits, but what deserves to be there, and what should be loaded only when it is needed.

The third: the harness. It is the scaffolding around the model, that is, the loop, the retries, the spending limits, the record of what happened and the approval gates. When a long-running agent falls over, it is almost never the model's fault: it is that the harness did not exist.

Why it matters and what you gain

Why it matters. Today you design by instinct and explain by analogy. That works with clients, but it collapses at two tables: in front of an engineer, and in front of a hospital's chief technology officer. With the vocabulary, you design on purpose and can justify every decision.

What you will be able to do that you cannot today. Look at any of your six systems and say, on a single page, which circuit runs, which tools it has, where the approval gate sits and what is measured. And spot, just by reading a tool description, why an agent is misusing it.

The deliverable for these two days: one page per system with its approval gate marked, and the laboratory set up. A question to sit with while you listen: of your six systems, how many are genuinely agents, and how many are workflows you call agents?

In one sentence

Step two. Evaluations and transcript analysis. Days three to ten, forty-five hours. It is the longest step in the route, and rightly so: it takes eight of the thirty-three days.

In one sentence: learning to know, with a number, whether one of your agents has improved or got worse.

The method, in five moves

The method has five moves, and the first one surprises everybody: you do not start by defining metrics. You start by reading transcripts, one at a time, and writing down in a single sentence what went wrong. Nothing more.

Second move: group those notes into named failure modes. There is no universal catalogue of failures; the catalogue for your agents comes out of your transcripts. That taxonomy is the real product of this step, more than any tool.

Third: decide what is measured by code and what by a judge. If the failure is verifiable, for instance that a phone number has eight digits or that an appointment falls inside consulting hours, that is code, and it is cheap. If the failure is a matter of judgement, for instance that the agent sounded cold or promised something it cannot deliver, that is a judge.

Fourth: write binary judges, one per failure. Binary means the answer is yes or no, not a score out of ten, because a score out of ten cannot be audited. And before you use a judge, you measure the judge: how often it agrees with the labels you applied by hand. A judge that does not agree with you is not a metric, it is noise with decimal places.

Fifth: build seed scenarios, run everything on every change, and read the trend.

Why this step carries the most weight

Why it matters. This is the largest gap against the job advert, and the one a hospital or an investor will demand before paying you anything.

The good news is twofold. You already have the instinct: the line you wrote into the Cofepris agent, that a valid JSON does not constitute an approval, is precisely the thesis of this step. And you have the raw material almost nobody has: Retell calls and GoHighLevel conversations, real ones, in Spanish, from a specific domain. That cannot be bought.

What you gain and how it holds

What you will be able to do that you cannot today. Say, with a number, whether Valeria or the GoHighLevel guardian improved or got worse after a change of prompt. Hand a client, alongside the agent, the taxonomy of failures and the suite that watches it. And stop fixing agents by symptom: you will know the exact line of the transcript where it went off.

And here is the rule that holds the whole free route together. In the six-month version it was one hour every Friday reading transcripts. Compressed to six hours a day, it becomes the first hour of every day, before anything else. That habit is what the four-thousand-two-hundred-dollar cohort would have imposed on you by calendar. Without it, this step becomes four courses watched and zero failures named.

In one sentence

Step three. SQL and the scoreboard. Days eleven to fourteen, twenty hours.

In one sentence: to stop eyeballing your numbers and start asking them questions.

The whole syllabus

What you learn. The syllabus fits on one line: SELECT, filters, joins between tables, grouping, window functions and dates. That is all of it. You do not need more for ninety per cent of the questions a business asks.

Then two practical things. How to point DuckDB at your GoHighLevel exports, your Retell logs and your file of contacted doctors, and ask them questions without setting up a server or moving the data anywhere.

And how all of that is arranged into a star schema: one fact table, which at Flow is the funnel, that is, message, reply, appointment, proposal, sale, with dimension tables around it, that is, contact, campaign, agent, speciality and city. In that shape, any business question becomes a short join rather than a fresh script.

Why four consecutive days

Why it matters. Your data sits in six different places, and today every business question is either a new script or a look with the naked eye. Without SQL there is no scoreboard. Without a scoreboard there is no observability. And without observability, the evaluations from step two are left hanging: you will know the agent improved, but not that it produced one more appointment.

In the six-month version this step ran in parallel with evaluations, three hours a week, so as not to burn out. At six hours a day that trick is no longer needed, and it would in fact get in the way: four consecutive days of nothing but queries fix the syntax far better than twenty scattered afternoons.

What you gain

What you will be able to do that you cannot today. Answer which sequence produces the most positive replies, what an appointment costs by channel, or how many outreach messages you have sent today and who sent them. In one line you wrote yourself, in under ten minutes, without asking Claude for the SQL.

And have the half past seven summary in Slack come out of a query rather than a file read by hand. That is the exit criterion for this step: you write the query. Claude reviews it.

In one sentence

Step four. Observability and the thread that leads to the money. Days fifteen to eighteen, twenty hours.

In one sentence: being able to say what each appointment produced by one of your agents actually costs.

Traces and spans

What you learn. First, two words. A trace is the complete run of an agent, seen as a tree. A span is each branch of that tree: a call to the model, a call to a tool, with its input, its output, its tokens, its cost and its latency.

Second, how to tag. A trace without a tag is an orphaned data point. With the contact and the campaign hung on it, that same trace can be joined to the fact table from step three, and that is where the technique turns into money.

Third, the full loop: how to turn a failed trace into an evaluation case. Step four feeds step two. Every failure that appears in production goes into the suite and never happens again without you finding out.

Why it matters

Why it matters. Today you know your agents run. You do not know what each appointment they produce costs, nor at which step they get stuck.

The job advert asks for it in these words: tie agent actions to pipeline and revenue. Without that you cannot charge for outcomes, which is exactly the model you want to sell, nor defend a contract with a hospital that will ask you about unit costs.

What you gain

What you will be able to do that you cannot today. Say, with last week's data, what each agent did, what it cost and what it produced. Find the exact trace of a production failure in five minutes, instead of reconstructing it from memory. And set a price per outcome knowing your real cost per outcome.

The deliverable: two Modal applications instrumented with traces, and one weekly line per agent in Slack. When that line exists and nobody has to assemble it by hand, the step is closed.

In one sentence

Step five. Reading and debugging Python. Days nineteen to twenty-three, twenty-five hours.

In one sentence, and this sentence matters: this is not learning to programme from scratch. It is learning to read fluently what Claude writes.

The syllabus, and what is left out

What you learn. Functions, lists and dictionaries, exceptions and what triggers them, modules and environments, files and JSON, requests to an API, environment variables and secrets, event logging and unit tests.

And what is deliberately left out: algorithms, advanced data structures, object-oriented programming beyond being able to read it. None of that is needed for what you have to do.

At six hours a day, weeks zero to seven of CS50P fit into five days. That is intense, but the material is designed for self-study and the problem sets are short.

The three incidents of the year

Why it matters. The three incidents that cost you the most time this year were all solvable by reading a few lines. The variable that enabled sending from your main mailbox. The local routine that never fired. The binary that was outside the PATH.

None of the three was a hard problem. All three were expensive because the code was opaque to you. And there is a larger consequence: you cannot review someone else's code, neither Claude's nor that of the engineer you hire next year, without being able to read it. A reviewer who does not read is a rubber stamp.

What you gain

What you will be able to do that you cannot today. Open any of your sixty scripts and explain in two minutes what it does and how it fails. Read a traceback and know which line to look at. Write a pytest test unaided. And find a configuration risk by reading, before it turns into an incident.

These five days are the hardest stretch of the accelerated calendar. If any part of the route needs a buffer day, it is this one.

In one sentence

Step six. Agents the Anthropic way: the API, tools, MCP and the SDK. Days twenty-four to twenty-seven, twenty-two hours.

In one sentence: building the piece your technical portfolio is currently missing.

The API from the inside

What you learn. How the API works from the inside: messages, system prompts, structured output, tool use, prompt caching and context budgets. That set explains why one of your applications costs what it costs and why it sometimes answers slowly.

How a tool is described so that an agent uses it well, which is step one applied with your hands.

And how the Agent SDK saves you the loop: all that scaffolding of retries, limits and tool handling that you currently rewrite in every Modal application is already solved.

A governed MCP server

The heart of this step is learning to build an MCP server with governed access. Governed means four answers in writing: what it reads, what it writes, what requires approval and what gets logged.

Why it matters. This is the central technical piece of the job advert, which puts it like this: MCP servers, skills and applications connected to the CRM. Your ghl-flow server exists, and that alone puts you ahead of almost any candidate. But today it has no defined scopes, no per-call logging, and no write tool behind a gate. In other words: it works, but it cannot be audited.

What you gain

What you will be able to do that you cannot today. Rebuild ghl-flow as a governed MCP server, with free reads, a single write tool that leaves a proposal for human approval, and every call logged. And explain it to a chief technology officer in ten minutes.

That is your first portfolio piece as a go-to-market engineer. Not a course passed: a system another engineer can review.

In one sentence

Step seven. Commercial systems, as an engineer. Days twenty-eight to thirty, eighteen hours.

In one sentence: to stop using your commercial tools and start designing them.

The CRM from the inside

What you learn. The data model of a CRM from the inside: contacts, opportunities, stages, activities, fields and triggers. What actually happens when an automation moves an opportunity from one stage to the next.

RevOps as a discipline, which sounds like jargon and is the opposite: it is shared definitions. What counts as a lead, what counts as an appointment, what counts as a sale, and everyone at Flow counting the same way. That is where half the scoreboards in this industry fall apart.

Waterfall enrichment with a cost per hit: querying providers in order until the data appears, and knowing what each hit cost.

Deliverability and WhatsApp

And deliverability as a system, not as a trick: domains kept separate from the main one, warming, authentication, daily caps and watching complaints.

Plus the WhatsApp rules: templates, the twenty-four hour window, and Meta's price change of the first of October, two thousand and twenty-six, which changes your cost per conversation.

Why it matters. You know GoHighLevel as an advanced user; the advert asks you to know it as an engineer. And you have an email engine that has been paused since July because of a deliverability problem that willpower does not fix: a runbook does.

What you gain

What you will be able to do that you cannot today. Write Flow's revenue data dictionary, in a form another engineer can follow without asking you. Calculate the Score Cazador with a script instead of by hand. Restart the email engine without putting the main domain at risk.

And run one complete circuit end to end, that is, list, agent, gate and appointment, measured on the scoreboard you built in step three.

In one sentence

Step eight. Experimentation and propensity. Days thirty-one to thirty-three, fifteen hours. It is the last numbered step and the shortest.

In one sentence: swapping the impression for the result.

Designing the test before launching it

What you learn. The first thing is to design an A B test before launching it, not afterwards. That means four things written down: the hypothesis, the primary metric, the sample size and the stopping rule.

The primary metric is one metric. If there are three, one of them always wins. And the stopping rule is fixed in advance, because halting a test on the day the number looks pretty is the most common, and most elegant, way of fooling yourself.

You also learn to recognise noise. At small volumes, two identical sequences give different results. Knowing how many contacts you need before you start saves you months of false conclusions.

Propensity that explains itself

The second thing is propensity. Logistic regression as a first model: which variables predict that a contact will reply, and how to read the coefficients so you can explain the recommendation in words.

That ability to explain itself matters more than a couple of points of accuracy. The advert asks for it literally: a predictive model that explains itself. A model that is accurate and cannot be explained can neither be sold to a doctor nor defended in front of a client.

And the third: not confusing correlation with effect in your own data. That contacted doctors buy more does not prove the contact works, if you contacted the ones who were going to buy anyway.

What you gain

Why it matters. Your Score Cazador is today a heuristic with weights set by eye. It works, and it was the right call to get started. But even six weeks of scoreboard give you data to begin replacing it with something that learns and explains itself.

What you will be able to do that you cannot today. Know whether one outreach sequence is better than another with a written result, win or lose. Rank the hundred daily outreach messages with a model that says why each one goes first. And show a client the effect of a campaign without crediting it with what would have happened anyway.

In one sentence

Step nine, and it runs across the others: days twenty-four to thirty-three, eight hours in total, roughly one hour at the end of each of those days.

In one sentence: making the repository defend itself, without you present.

What gets automated

What you learn. Getting the tests and the evaluation regression to run by themselves on every proposed change, without anyone having to remember. Getting the main branch protected, so nothing can be written to it directly. Review conventions, so that giving and asking for feedback does not depend on the mood of the day. And versioning for your skills, so you can go back.

It is the shortest step and the least noticeable while you do it. It is also the one that saves the most work afterwards.

Why it matters

Why it matters. The advert asks you to grow a codebase with many contributors. Your audit of the eleventh of September found skills with no version, which is exactly the symptom of a repository that depends on one person's memory.

And you are going to add engineers. The repository has to protect itself without you present, because if the only quality control is your personal review, you become the bottleneck of your own company.

What you gain

What you will be able to do that you cannot today. Receive a change from another person, or from Claude, and know within two minutes whether it broke something, because the tests have already run on their own.

And be able to say the sentence nothing reaches main without passing the evaluations, and have it be true rather than an intention.

How this revision works

Final revision. Fifteen questions across the nine steps.

It works like this: you hear the question, there is a short pause, and then the answer arrives. Answer first yourself, out loud or in your head. If you miss three or more from the same area, that step is not closed, however many videos you have watched.

Questions one to five: vocabulary and evaluations

One. What is the difference between a workflow and an agent?

A workflow follows steps you fixed in advance. An agent chooses its own next step, in a loop, until it finishes or runs out of budget.

Two. Name three of the five agent design patterns.

Chaining, routing, parallelisation, orchestrator with workers, evaluator with optimiser.

Three. An agent is misusing a tool. What is the first suspect?

The tool description. It is a prompt, not documentation.

Four. How does an evaluation begin?

By reading transcripts one at a time and noting in a single sentence what went wrong. Not with metrics.

Five. How do you know whether your judge is any good?

By measuring how often it agrees with the labels you applied by hand. First you evaluate the judge, then the agent.

Questions six to ten: data, traces and code

Six. What is Flow's fact table?

The funnel: message, reply, appointment, proposal, sale. The dimensions are contact, campaign, agent, speciality and city.

Seven. What is DuckDB for in this route?

For querying your GoHighLevel exports, your Retell logs and your file of contacted doctors on your own Mac, without setting up a server.

Eight. What is a trace, and what is a span?

The trace is the complete run of an agent, seen as a tree. The span is each branch: a call to the model or to a tool, with its cost and its latency.

Nine. What does a trace need before it can be joined to the scoreboard?

The business tag: the contact and the campaign.

Ten. In the Python step, what is the stated goal?

To read and debug what Claude writes. Not to programme from scratch.

Questions eleven to fifteen: MCP, commercial and method

Eleven. Which four things define a governed MCP server?

What it reads, what it writes, what requires approval and what gets logged.

Twelve. What is RevOps, without the jargon?

Shared definitions. Everyone counting a lead, an appointment and a sale the same way.

Thirteen. Which four things are written down before launching an A B test?

The hypothesis, the primary metric, the sample size and the stopping rule.

Fourteen. Why prefer a propensity model that explains itself?

Because you have to be able to tell a client why one contact goes first. A model that is accurate and cannot be explained cannot be defended.

Fifteen, and the most important. What is the one non-negotiable rule of the free route?

The hour spent reading transcripts from your own agents. At six hours a day, it is the first hour of every day. It is what replaces the paid cohort.

Closing

That is all of them. Twelve or more without hesitating and you are in good shape. If you missed several from the same area, go back to that track before carrying on with the calendar.

And remember the criterion that runs through the whole route: during these thirty-three days, Claude reviews what you wrote first. It does not write it for you.