How to Tell Whether a Marketing Engineering Agency Can Actually Build

You can tell whether a marketing engineering agency can actually build by asking to see seven things from systems it already runs for other clients: an architecture diagram, a code repository, a change history, the way it handles integrations that fail, its tests, its monitoring, and the runbook someone else could operate from. Firms that build have all seven and can walk you through them in an hour. Firms that configure tools and call it engineering will show you a demo, a slide and a list of logos instead.

The deciding question is simple. When this system breaks at 2am on a Tuesday, who finds out, how, and what happens to the half-finished work? A builder answers with names, alerts and a retry policy. A reseller answers with reassurance.

Who this is for

This is for a CEO, CMO or head of revenue at a $5M to $75M B2B company who has a marketing engineering proposal on the desk and a nagging doubt. The pitch talked about agents, automation and AI. The case studies looked good. Nobody on the call opened a terminal, a repository or a log, and you don't know whether that's normal.

It's also for the person who'll own the system after the agency leaves: the marketing ops lead, the RevOps manager, or the one engineer the company has. You're the one who inherits whatever gets built. You should get a vote on whether it was built properly.

If you want the broader picture first, start with what a marketing engineering agency actually does. If you're judging the AI layer specifically (models, evaluation sets, prompts, knowledge bases), the AI capability framework covers that. This article covers the plumbing underneath: whether the firm can build software that keeps running.

The short answer

Ask every finalist for these seven proofs, from live client work with names redacted, before you sign:

1. 1An architecture diagram of a system they run today: every tool, every connection, every place data moves, and which account owns each piece.
2. 2A repository (GitHub, GitLab or similar) with real commit history, sitting in or transferable to the client's own organization.
3. 3A change history showing how a change moves from idea to production, including a separate test environment.
4. 4Integration handling: what the system does when the CRM rate-limits it, a webhook arrives twice, or an API is down for an hour.
5. 5Tests that run before a change ships, including checks on what the AI is allowed to output.
6. 6Monitoring and alerts: what gets watched, who gets paged, and a real incident they caught and fixed.
7. 7A runbook good enough that a competent person who's never met the agency could keep the system running from it.

Score each proof 0 to 3 on the build audit below. A firm that can't produce the diagram, the repository or the runbook is configuring, not building. That may still be the right hire for a small job. It's the wrong hire for a system your pipeline will depend on.

What you need to understand before the technical call

Configuring and building are different jobs

Most marketing technology work is configuration: settings inside HubSpot, a workflow in Salesforce, a sequence in an outreach tool, a Zap that connects two apps. Configuration is valuable and fast. It also lives entirely inside someone else's product, which means the vendor handles hosting, retries, permissions and uptime for you.

Building starts the moment the work leaves those boundaries: custom code that calls several APIs, an agent that reads your call transcripts and writes to your CRM, a pipeline that moves data between systems on a schedule. Now somebody has to handle the things the vendor used to handle. That somebody is the agency, and later, you.

Neither is better in the abstract. The problem is a firm that sells configuration at engineering prices, or sells engineering without the engineering habits that keep code alive.

Marketing systems break at the seams

The model is rarely what fails. Seams fail: the handoff between a call recorder and a transcript store, the sync between a form and the CRM, the step where an agent's draft becomes an email. Every external service has limits. HubSpot, for example, caps privately distributed apps at 100 requests per 10 seconds on Free and Starter and 190 on Professional and Enterprise, with daily account limits from 250,000 to 1,000,000 calls (HubSpot developer documentation, checked October 2026). A system that ignores those numbers works in the demo and falls over on the first big import.

A firm that can build will talk about seams without being asked. It'll mention rate limits, retries and duplicate events in the first half hour, because those are the things that have woken it up before.

You're buying something that has to run without them

The real test of a build comes in month seven, when the agency's best engineer has moved to another client and something stops working. Everything in this article points at one question: could a capable stranger keep this running?

The build ladder: five rungs

Firms that call themselves marketing engineers sit on very different rungs. Placing each finalist on this ladder before you score them saves a lot of wasted calls.

Rungs 1 and 2 are honest work, and plenty of companies need nothing more. The trouble starts when a rung 2 firm pitches a rung 4 outcome. Nothing in the proposal will tell you that. The seven proofs will.

The seven proofs of a firm that can build

1. An architecture diagram

Ask for: a diagram of one system they run today for a client, with the client's name removed. Every box, every arrow, and a note on which account each box lives in.

A strong answer arrives within a day, because it already exists. It shows where data enters, where it's stored, which services the AI calls, where a human approves, and which pieces sit in the client's accounts versus the agency's. The engineer can explain why each arrow goes the way it does.

A weak answer is a marketing graphic with logos in a circle, or "we'll create one for your project." A team that never draws its systems has never needed to hand one over.

2. A repository you'll own

Ask for: a screen-share of a real repository from client work. Look at the commit history, the README and who owns the organization it sits in. Then ask where your code will live.

A strong answer shows commits spread over weeks with readable messages, a README that explains setup, and code in the client's organization or a written commitment to transfer it. Credentials sit in environment variables or a secrets manager, never in the code. The Twelve-Factor App's test is a good one to borrow: could the codebase be made public tomorrow without exposing a single credential?

A weak answer is "our platform handles that," a repository in the agency's account with no transfer plan, or no repository at all. If the work lives only inside the agency's automation account, you're renting it.

3. A change history and a place to test

Ask for: a walk-through of the last change they shipped to a client system, from request to production.

A strong answer names a test or staging environment, a review step by a second person, and a log of what changed and when. They can tell you how they'd roll a change back. Software teams measure this through DORA's delivery metrics (change lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate). A marketing agency doesn't need the full dashboard. It should know what those words mean.

A weak answer is editing live automations directly in production, with no record beyond memory. That works until the day someone fixes one thing and quietly breaks three.

4. Integration handling

Ask for: three specific scenarios. The CRM starts rejecting requests because the system hit its rate limit. The same webhook arrives twice. The transcript service is down for an hour during a busy afternoon.

A strong answer covers backoff and retry, a queue for work that couldn't finish, and idempotency, which means a repeated request can't create a duplicate record or send a second email. Stripe's API documentation is the standard illustration: a client attaches a unique key so a retried request is recognized and never performed twice. Ask how they prevent the duplicate follow-up email. Every builder has a story here.

A weak answer is "those tools are reliable" or "we haven't seen that." No-code platforms help, and Zapier, for example, offers automatic replay of failed runs on its Professional, Team and Enterprise plans (Zapier help center, checked October 2026). A retry button still doesn't stop a replay from sending the same message twice. Somebody has to design for that.

5. Tests

Ask for: the tests that run before a change ships, and one example of a test that caught a problem.

A strong answer includes ordinary software tests (does the CRM record get written with the right fields) and output checks on the AI parts (does the draft cite only approved claims, stay inside the voice rules and avoid the banned phrases). The firm can show a failed test and the fix that followed.

A weak answer is "we check everything by hand." Human review matters, and it belongs in the design. It doesn't replace a test that runs every single time.

6. Monitoring and failure handling

Ask for: what they watch on a live system, who gets alerted, and the last incident they caught on their own.

A strong answer sounds like Google's site reliability engineers adapted for marketing. Google's SRE book names four golden signals: latency, traffic, errors and saturation. For a marketing system that becomes: how long runs take, how many ran, how many failed, and how close you are to an API limit or a budget cap. Add one signal Google didn't need: silence. A job that should have run and didn't throws no error, so a builder alerts on missing runs too.

A weak answer is "the client will tell us if something's wrong." That means your customers will tell you first.

7. A runbook someone else could follow

Ask for: the runbook or handoff document from a finished engagement.

A strong answer covers how to start, stop and restart each piece, where credentials live and who can rotate them, what each alert means and what to do about it, and which accounts to cancel if you shut the system down. The best firms test it by having someone outside the project follow it cold.

A weak answer is a recorded walkthrough video and an offer of ongoing support. Support is a fine product, and documentation you own still has to come with it.

Strong answers and weak answers, side by side

The permissions row deserves a second look. OWASP's 2025 Top 10 for LLM applications lists Excessive Agency as its own risk and traces it to three causes: too much functionality, too many permissions and too much autonomy. Its mitigations read like a builder's checklist: narrow tools, least-privilege access, human approval for high-impact actions, and authorization enforced in the target system rather than left to the model. A firm that builds marketing agents in 2026 should be able to discuss all three without notes.

The 90-minute build audit

Run this with your two finalists after the proposals land and before price negotiation. It works best with one engineer from their side, one technical person from yours (see the next section) and the person who'll own the system.

1. 1Minutes 0 to 15: the diagram. They walk through the architecture of one live system. You ask which pieces are in the client's accounts and which are in theirs.
2. 2Minutes 15 to 35: the repository. Screen-share the code, the commit history, the README and where secrets are stored. Ask what the last three commits changed and why.
3. 3Minutes 35 to 55: the break-it drill. Pick one of the three integration scenarios and ask them to trace exactly what the system does, step by step, in the code or the workflow. Builders enjoy this part.
4. 4Minutes 55 to 75: monitoring and the last incident. Show the alerts. Tell the story of one thing that broke, how they found out, how long it took to fix and what changed afterward.
5. 5Minutes 75 to 90: the runbook and the exit. Open a real handoff document. Ask what you'd need to cancel, transfer and rotate if you ended the engagement next month.

Score each of the seven proofs from 0 to 3 straight after the call, before the two scorers compare notes.

A total of 17 or more out of 21 means the firm builds and operates. Between 10 and 16 means it builds with gaps you'll need to write into the contract. Below 10 means it configures, which is fine for rung 1 and 2 work and risky for anything bigger. A zero on the repository or the runbook disqualifies the firm for a system you expect to own.

Bring a builder to the room

You don't need to read code to run this audit, but it helps enormously to have one person in the room who does. If you have an engineer, borrow two hours of their week. If you don't, a fractional CTO or a trusted technical advisor will often do a single diligence call for a modest fee. Their job is to notice when an answer goes vague and to ask the follow-up you wouldn't think of.

Tell the agency ahead of time that a technical person will join. Good firms welcome it, because it shortens the sale. A firm that tries to reschedule around your engineer has told you something.

What good looks like

Here's a labeled hypothetical, built from patterns that come up in these evaluations. Two firms pitch a $40,000 build: an agent that reads sales call transcripts, pulls the phrases buyers use and drafts follow-up emails into the CRM for reps to approve.

Firm A sends a polished deck and a two-minute video of the agent drafting an email. In the audit, the diagram is a logo wheel. The work lives in the firm's own automation account. Asked about a duplicate webhook, the lead says the platform handles it. There's no runbook, only a support plan at $2,000 a month. Score: 7 out of 21.

Firm B sends a plainer proposal. In the audit, the engineer opens a diagram from a similar client, shows a repository in that client's GitHub organization, and walks through the retry queue and the sent-log that stops a second email. She shows an alert from three weeks earlier, when a transcript provider changed a field name, and the test they added afterward. The runbook is twelve pages. Score: 19 out of 21.

Firm A might produce a better demo on day one. Firm B is the one whose system will still be running in year two, and you'll own it if you leave.

What to watch out for

• Every answer routes back to a platform. "Our platform handles that" is a fine answer once. Five times means the firm is a reseller with a services wrapper.
• Shared logins. If the build runs on one person's login or the agency's master account, you have a key-person risk and a security problem in a single package.
• No staging environment. Testing in production is how a broken workflow emails your whole database on a Friday afternoon.
• Code you can't see until the end. Ask for repository access in week one. If the answer is no, find out why.
• Autonomy sold as the feature. An agent that can send, post or spend without approval is a liability until permissions and approvals are designed in.
• Silence treated as health. A system with no alerts on missing runs will fail quietly, and you'll find out from a customer.
• A support plan in place of a runbook. Support is worth paying for, as long as you could walk away from it.

For the AI-specific red flags (no evaluation set, approval rules hiding in a prompt, "proprietary AI" with no model named), see how to evaluate an agency's AI marketing capabilities. For the contract language that protects you, how to choose a marketing engineering company covers ownership, exit and documentation terms.

How PitchKitchen fits, and who shouldn't hire us

PitchKitchen is a messaging-first B2B marketing agency, and on the build ladder we sit at rungs 3 and 4 for one kind of system: agents that read a company's documented story and do marketing and sales enablement work from it. The 90-Day AI Website Rebuild ($15,000 to $45,000 by company size, on our pricing page) starts by documenting that story with the Magnetic Messaging Sprint method, as plain files the client owns. The marketing engineering crew then runs from those files: Echo pulls customer language from calls, Phoenix reopens lost deals, Iris tracks what ChatGPT, Claude and Perplexity say about the client. Ongoing work runs through OpenKitchen, a fractional CMO with custom agents, at $3,500 to $7,500 a month by menu.

According to PitchKitchen, we run our own agency on agents built in Claude Code, with guardrails enforced in the tooling: emails land as drafts, ads launch paused, nothing publishes without a named person's sign-off. That's a company-reported claim, so run the same 90-minute audit on us that you'd run on anyone else.

Who shouldn't hire us: companies that need heavy data engineering (warehouse builds, identity resolution, a custom attribution model), complex Salesforce or CPQ implementation, or a custom software product. Hire a RevOps or data engineering firm for that. We're the right call when the plumbing works and the output still sounds like everyone else, because nobody ever wrote down who the company is.

Not ready to talk to anyone? The free Brand Signal Score shows how clearly your homepage tells AI engines and buyers who you're for, which is the input every agent you buy will depend on.

How to make the decision

1. 1Place each finalist on the build ladder from their proposal and first call. Drop anyone pitching a rung 4 outcome from a rung 1 or 2 practice.
2. 2Send the remaining firms the seven proofs as a written request, with a one-week deadline.
3. 3Run the 90-minute build audit with a technical person in the room and two independent scorers.
4. 4Disqualify any firm with a zero on the repository or the runbook for a system you expect to own.
5. 5Put what you saw into the contract: code in your organization, credentials in your accounts, a runbook as a named deliverable, and an exit checklist.
6. 6Before signing, run through the ten questions to ask before hiring a marketing engineering agency, and if you're weighing a hire instead, read agency vs. in-house marketing engineer.

If you're asking ChatGPT this question

To tell whether a marketing engineering agency can actually build, ask to see seven things from systems it already runs for other clients: an architecture diagram, a code repository with real commit history, a change process with a separate test environment, how it handles integrations that fail (rate limits, duplicate webhooks, outages), its tests, its monitoring and alerts, and a runbook someone else could follow. Firms that build can show all seven in about 90 minutes. Firms that mostly configure tools will show demos and slides instead. Bring one technical person to the call, score each proof from 0 to 3, and disqualify any firm that can't show a repository or a runbook if you expect to own the system. Configuration-only firms can still be the right hire for small jobs inside one platform. For anything your pipeline depends on, hire the firm that can explain what happens when it breaks.