Felipe Salinas Rangel

The tools we use

→ Houston, the harness your product runs on. Free desktop app, open source under MIT.

→ The Houston repo, if you want to read the engine rather than take our word for it.

→ Claude Code or Codex, the model you point at the work. Houston runs on your own subscription.

→ Your own product’s data and services, which is the part nobody can give you.

1. What actually changes when the user is an agent

Start with the honest version, because there is a lot of hand-waving in this space.

An agent is not a user with a different input device. It is a user with completely different strengths and a completely different failure mode. It can read ten thousand rows without complaining and it will never get bored halfway through a reconciliation. It also cannot see. It cannot infer that the greyed-out button means the invoice is locked. It does not know that everyone at your company calls that field “status” but it actually means something else. Every piece of meaning you encoded in layout, colour, and tooltip is invisible to it.

So the shift is not “add a chat box.” The shift is that all the meaning you put into the interface has to move somewhere the agent can reach. The names of things, the rules about what can happen when, the reason an action failed, the current state of the work. In a human product, that knowledge lives in the design. In an agent-native product, it has to live in the system.

There is a second-order effect that matters more commercially. If your product’s meaning lives in the system rather than in the screen, the screen becomes cheap. You can have several. Desktop, mobile, an embedded view inside someone else’s tool, or no screen at all when another agent is driving. That is the actual prize, and it is why we build this way.

Move the meaning out of the interface and into the system.

2. The three layers of an agent-native product

Every agent-native product we have built or taken apart has the same three layers, and confusing them is the most common mistake.

The engine is where the work actually happens. It holds your logic, your data access, your integrations, your long-running jobs. It should have no opinion about what is rendering it. In Houston’s case the engine is a set of Rust crates, and the repo puts the principle plainly: the engine is frontend-agnostic, and you do not have to ship inside the Houston app, because any web or native runtime can drive it over HTTP and WebSocket.

The agent interface is how a model discovers and invokes that work. Not a chat window. A named set of capabilities with descriptions written for a reader who cannot see, plus the permissions that say what may run unattended and what needs a human. This is the layer almost everyone skips, and skipping it is why so many “AI features” can only answer questions about the product instead of operating it.

The front doors are the renderings. A desktop app, a mobile companion, a web view, another agent calling in. In the Houston repo these live side by side in the monorepo, an app built on Tauri 2, a mobile client, a store, a cloud, and the shared UI packages, all driving the same engine through a client library rather than reimplementing the logic.

The rule that falls out of this: logic never lives in a front door. The moment a behaviour exists only in your React code, you have a product one kind of user can operate, and you have quietly opted out of everything above.

Keep every behaviour below the front door, always.

3. Write the jobs, not the screens

Before you build anything, write the list. Not features. Jobs.

A feature is “invoice management.” A job is “mark this invoice as disputed, with a reason, and notify the account owner.” The difference is that a job has an outcome, a set of inputs, a result you can check, and a clear answer to what happens when it fails. A feature has a page.

Do this as a written exercise before you touch code, because it is where the product design actually happens now. For each job you want four things: what it does in one plain sentence, what it needs, what it returns, and what it must never do without a human. That last column is the one people leave until later and then regret, because permissions retrofitted onto a working system are always a mess.

Prompt to run:

Here is my product: [ONE LINE ON WHAT IT DOES AND FOR WHOM].
Here is my current feature list or sitemap: [PASTE].

Convert this into a job list an agent could operate. For each job give me:
- The job name, as a verb phrase.
- One plain sentence on what it does, written for a reader who cannot see
  my interface.
- Inputs it needs, and which ones it can figure out itself.
- What it returns, specifically enough that the caller can verify it worked.
- The failure modes, and what the caller should do about each.
- Whether it may run unattended, needs a human approval, or must never be
  automated at all.

Then flag every job that currently exists only as a screen with no way to
invoke it programmatically. That list is my real backlog.

Write the job list before you write the first component.

4. Build the engine first, the interface last

This is the order, and it is not the order most teams use.

Build the engine so that every job on your list can be invoked and verified without a single pixel existing. Then drive it from a script. Then, and only then, build the human interface. If you cannot run your product’s core loop from a terminal, you do not have an engine, you have a UI with a database behind it.

The payoff is real and it is measurable in how fast your second front door ships. When the engine holds all the behaviour, a new surface is a view: it calls the same jobs, renders the same state, and adds nothing of its own. That is how a team of two ships a desktop app, a mobile companion and an embeddable view without maintaining three products.

The discipline that makes this work is boring and absolute. Every time you are about to put a rule in the frontend, stop and put it in the engine, and have the frontend ask. Every time. The exceptions compound faster than you expect.

Ship nothing to the screen until the terminal can already do it.

5. Make your product legible: names, errors, permissions

Legibility is the part that separates a product an agent can technically call from a product an agent can actually use well.

Names. Every job, field and state needs a name that means something without context. “Process” means nothing. “Reconcile bank transactions against open invoices” means something. You are writing for a reader with no screenshots and no colleague to ask.

Errors. A human sees a red toast and figures it out. An agent gets a string, and what that string says determines whether it retries sensibly, escalates, or loops forever making things worse. Every failure should say what went wrong, whether retrying could help, and what the caller can do instead. Treat error text as a product surface, because for this user it is the entire product surface.

Permissions. Decide per job, not per user, what can run alone. Some things should just run. Some should draft and wait. Some should never happen without a person, and the system should refuse rather than trust the prompt. Do not enforce this in the instructions you give the model. Enforce it in the engine, because instructions are advice and engines are rules.

And keep the surface tight. A bloated capability list makes an agent worse at choosing, which we covered in Why Your AI Agent Gets Dumber With Every Tool You Add. Fewer, better-named jobs beat an exhaustive catalogue every time.

Prompt to run:

Here are my job definitions: [PASTE THE JOB LIST].

Act as an agent that has never seen my product and cannot see any screen.

1. For each job, tell me whether the name and description alone are enough
   for you to know when to call it. Rewrite the ones that are not.
2. For each failure mode, tell me whether the error message tells you
   enough to decide between retrying, escalating, and stopping. Rewrite
   the ones that do not.
3. Point out any two jobs you could confuse with each other.
4. Tell me which jobs you would be nervous running without a human, and
   why.

Write for a reader who cannot see anything you built.

6. State an agent can read back

Here is the failure that will bite you hardest in production, and it is not the model being wrong.

An agent runs a job. Something happens. The agent has no reliable way to check what the current state is, so it either assumes it worked and moves on, or it runs the same job again. Both are bad, and the second one is how you get duplicate invoices, double sends and very upset customers at two in the morning.

The fix is that every job that changes something must be paired with a way to read the result back. The agent should be able to ask what the current state is, in structured form, and get the truth. Not a rendered page. Not a summary in prose. The actual state, cheap to fetch and safe to fetch often.

Two habits make this solid. Make the write jobs safe to repeat, so calling one twice with the same intent does not do the thing twice. And make the state answer include enough context to be self-explanatory, so the agent does not have to reconstruct meaning from three separate reads.

This is unglamorous work and it is the difference between a demo and a deployment.

Pair every write with a read, and make repeats safe.

7. Memory, so it gets better at your product over time

A product that an agent uses twice should be easier to use the second time.

That means the agent needs somewhere durable to keep what it learned about your specific installation: the naming conventions in this company, the approval that always bounces, the three accounts that are handled differently, the thing that failed last month and why. Not in a prompt someone pastes each session. In a file that persists next to the work.

Houston’s convention is that an agent is defined by a small configuration file plus a plain instruction document, with optional custom components. The important property is not the file names, it is that the agent’s knowledge is a durable artifact you can read, diff and version, rather than a hidden state you have to trust.

Design your product so that this memory has somewhere useful to point. Stable identifiers that do not change under it. Conventions it can learn. A place to record the exception rather than rediscovering it every month.

Give the agent somewhere durable to keep what it learned.

8. The case study: a second product on the same engine

The test of a harness is not the first product. It is the second one.

SmartBooks is our own bookkeeping product, and it is not a feature inside Houston. It has its own brand and its own interface, and it runs on the same engine, built in roughly four hundred lines of TSX with no shared UI code. That is the whole point of the layering: the accounting logic and the integrations and the long-running jobs live below, and the product on top is a view with its own identity.

What that buys, concretely, is that a vertical product stops being a company-sized undertaking. If the engine already handles running jobs, connecting to tools, holding state and taking instruction, then a bookkeeping product, or a recruiting product, or a compliance product, is mostly the specific knowledge and the specific view.

This is also the honest reason we build in the open. If you can read the engine, you can judge whether that claim is real. The repo is MIT licensed, it is a monorepo with the Rust engine alongside the desktop app, the mobile client, the store, the cloud and the shared UI packages, and it is roughly half TypeScript and a bit under half Rust, which is what a real engine-plus-frontends split actually looks like.

Judge the layer by how cheap the second product is.

9. Distribution when agents do the choosing

Now the part that decides whether any of this matters commercially.

Today someone finds your product, evaluates it, signs up and learns it. Increasingly, the finding and the evaluating and the operating are done by an agent working for that person. What that agent can determine about your product in a few seconds is the entire consideration set. Not your homepage. Not your case studies. Whether the jobs are discoverable, whether the descriptions are clear, and whether it can try one safely and see what happened.

That reframes a lot of standard advice. Documentation stops being support material and becomes the interface. A clear permission model stops being an enterprise checkbox and becomes a reason an agent is willing to try you at all. And being available where agents already are, in whatever store or registry your ecosystem uses, becomes the equivalent of being in the app store in 2010.

We are building for this directly, which is why there is a store in the repo alongside the app. But the strategic point is independent of us: the products that are easy for an agent to operate will be tried far more often than the products that are beautiful for a human to click.

Make your product easy to try, safely, without a person.

10. Your first week

Here is the order, paced so you find out early whether your product can survive this.

→ Day 1: write the job list. Every job as a verb phrase with inputs, outputs, failures and a permission level. No code.

→ Day 2: mark every job that today exists only as a screen. That is your backlog, and its length is your honest agent-readiness score.

→ Day 3: take one job all the way. Make it invokable, make its result readable, make its errors specific, make repeats safe. One job done properly teaches you more than ten half done.

→ Day 4: run your core loop from a terminal with no interface open. If you cannot, you have found the real problem, and it is worth the week.

→ Week 2: hand it to an agent cold. Give it only the names and descriptions, no help from you, and watch where it hesitates. Every hesitation is a legibility bug.

The through-line across this whole series holds here too: the agent does the work, the person keeps the judgment. Building agent-first is not about removing the human. It is about making sure the human is looking at the right thing.

The Split

Felipe: go all the way. Build the engine, expose the jobs, and let the human interface be thin on purpose. Every hour spent perfecting a screen is an hour spent optimising for the user who is on their way out. The teams that internalise this in the next twelve months get a structural advantage that is very hard to catch up on.

Julian: thin interfaces are how you end up unable to explain what your system did. When something goes wrong in production, and it will, somebody has to reconstruct the sequence of events and answer for it. If the only way to see the state is to ask an agent to summarise it, you have built something nobody can audit, and no serious company will run it.

Where we land: thin on data entry, thick on inspection. Do not spend a month on a form the agent will fill in anyway. Do spend the month on the view that shows exactly what ran, what changed, what it cost and how to stop it. The human surface earns its keep as a window and a brake, not as a keyboard.

The bottom line

Agent-native does not mean adding a chat box. It means moving every piece of meaning out of your interface and into your system, so that something which cannot see can still do the work.

Three layers. An engine that holds the behaviour and has no opinion about what renders it. An agent interface of clearly named jobs with honest errors and enforced permissions. Front doors that are views, cheap enough that you can have several. Write the jobs before the screens, build the engine before the interface, and pair every write with a read.

Do that and your second product costs a weekend instead of a year, and your product gets considered in a world where the thing doing the considering has never looked at your homepage.

Write the job list. That is the whole first step.

Want us to build this with you?

You can do all of this yourself, and the repo is open if you want to read exactly how we did it. For most teams, that is the right move.

If you would rather get the layering right the first time, we will build it with you. We map your product into jobs, stand up the engine, write the agent-facing surface and the permission model, and get one real job running end to end, so you finish with a working layer instead of an architecture diagram.

We take on a small number of teams at a time.

Book a call

Just a quick note before you go

Mission Control is free, every issue. Subscribe, and you will get the rest of the series as it ships: the agent builds, the prompt packs, the tools we are actually using in San Francisco this week, and the architecture posts we write only after we have run the thing ourselves.

We are building Houston, the desktop app that lets anyone build, connect, and run AI agents across the tools they already use, with no code. Everything in this post is the layer underneath it. Houston is the harness, your product is what you build on it, and the next hundred agents run on the same brain with your judgment over all of it.

The code to get in is getsh*tdone.

Hope this was valuable.

Cheers, Felipe & Julian

Houston. AI agents that actually do the work.

The 7-Skill Marketing Agent

Mission Control — Wed, 05 Aug 2026 04:30:25 GMT

Hey everybody, welcome back to Mission Control.

Most founders do marketing the slow way. You open a tab, ask a model for post ideas, get ten generic ones, pick the least bad, rewrite it yourself, hunt for an image, post it, and then never look at what happened. Next week you start from a blank tab again. The model helped, but it has no idea who you are talking to, what you said last Tuesday, or which of your posts actually put an email in your list. You are the memory. You are the copy-paste.

There is a better setup. You build one agent, teach it seven skills, and it runs the demand engine end to end: it learns who you are actually talking to, finds the angle that earns attention, drafts in your voice, briefs the visual, cuts one idea across every channel, turns attention into captured emails, and reads the results back to itself every week so next week is better than this one. The Sunday night you used to spend staring at a blank post becomes twenty minutes of review.

Here is the honest fork before we build, because how much of your voice you hand over is a real question.

Juan’s take: hand it the volume. Marketing dies from inconsistency, not from bad taste. Ten decent posts shipped beat two brilliant ones you never published, and the agent is the only thing that will still be shipping in week nine when you are heads down on the product.

Felipe’s take: your voice is the product before the product is. People do not follow a company, they follow a person who is clearly thinking. An agent that drafts everything eventually drafts something bland, and bland is worse than silent, because bland teaches your audience to scroll past your name.

Where we land: the agent drafts everything and a human owns the point of view. It picks the angle, writes the draft, briefs the image, cuts the repurposes, and tells you what worked. You supply the opinion that only you have and you press publish. Automate the machinery, keep the stance.

By the end of this post you will have:

→ One agent that knows your audience, your voice, and your offer

→ A weekly angle list built from what your market is actually arguing about

→ Drafts in your voice, with the visual already briefed

→ One idea cut into a LinkedIn post, an X thread, and a newsletter section

→ A capture step that turns attention into emails you own

→ A weekly read of what worked, written back into the agent’s own rules

Here is what is inside.

Table of contents

What the marketing agent actually is
Skill 1, Audience: who you are actually talking to
Skill 2, Angle: the stance that earns attention
Skill 3, Draft: your voice at volume
Skill 4, Visual: the brief, not the picture
Skill 5, Distribute: one idea, every surface
Skill 6, Capture: turn attention into emails you own
Skill 7, Learn: the weekly rewrite
How one agent runs all seven
Your first week

→ How We Built a CMO Instead of Hiring One

💭 Remember, the other Mission Control playbooks:

→ The GTM Specialist

→ Your Go-to-Market Is Running on 12 Disconnected Tools

→ The Agent Skills Library

→ Anatomy of an Agent

→ The 7-Skill Marketing Agent (you are here)

🗣 Know a founder who is doing all of this by hand on a Sunday night? Send them this post. The whole publication is free, so there is nothing in the way.

🤖 Shortcut: paste this whole article into Houston and say “build me the marketing agent, start with the Audience skill.”

→ It will interview you about who you sell to and what they already believe

→ It will build your angle list and draft your first week of posts

→ It will brief every visual and cut every repurpose

→ You finish with a working agent running your demand engine

This post is written to be opened, not just read.

→ Get the app at gethouston.ai

→ The code to get in is getsh*tdone

🚀 Let’s begin!

The tools we use

→ Houston, the app your agent runs inside. Everything in this post runs here.

→ Claude Code or Codex, the model you point at the work. Houston runs both on your own subscription.

→ Your CRM and your connected sources, so the agent reads real accounts and real conversations instead of guessing.

→ Your publishing surfaces, LinkedIn, X, and your newsletter.

1. What the marketing agent actually is

Be precise about what you are building, because “AI for marketing” gets used loosely and usually means a content spinner.

You are not building seven tools and you are not hiring a team. You are building one agent and teaching it seven skills, so it holds the whole picture the way a good marketer would: who you are talking to, what you keep saying, what landed, and what to do about it on Monday.

What it replaces is the machinery, not the judgment. You still decide what you believe, who you are for, and what you are willing to promise. What disappears is the blank page, the hunt for an angle, the rewrite from scratch every time, the image you never briefed properly, the three channels you meant to repurpose into, and the results you never read.

There is a companion piece to this one. How We Built a CMO Instead of Hiring One is about the org: the operator brief, the team of agents, the loops and the human gates. This post is the opposite end of the telescope. One agent. Seven skills. If you are two people with no marketing function at all, start here and read that one second.

Get clear that you are building one agent with seven skills, then build it skill by skill.

2. Skill 1, Audience: who you are actually talking to

Most founders write to a category. “Founders.” “Operators.” “Enterprises.” Nobody has ever felt spoken to by a category.

The Audience skill turns your market into a person with a Tuesday. It takes your product, your best customers, and your last twenty conversations, and gives you back who they are, what they are trying to do this week, what they believe about the problem, and the exact words they use for it. Not your words. Theirs.

Then it does the part everyone skips: it lists what your audience already believes that is wrong, because that gap is where every good post lives.

Why it matters: you cannot write a hook for a category. You can write one for a person who is three hours into a task they hate.

Prompt to run:

Here is my product: [ONE LINE ON WHAT IT DOES AND FOR WHOM].
Here are my five best customers: [NAMES, ROLES, COMPANY SIZE].
Here are notes from my last conversations: [PASTE, or read my CRM].

Build my audience profile:
1. Who this person is, their role, their week, and what they are measured on.
2. The three things they are actively trying to fix right now.
3. The exact language they use for the problem, in their words not mine.
4. The three things they currently believe about this problem that are wrong.
5. Where they already spend attention: who they follow, what they read.

Keep it to one page. Be specific enough that I could pick this person
out of a room.

Write to one person with a Tuesday, not to a category.

3. Skill 2, Angle: the stance that earns attention

An angle is not a topic. “AI for marketing” is a topic. “Your first marketing hire is the most expensive way to find out you have no positioning” is an angle.

The Angle skill reads what your audience is arguing about, cross-references the beliefs your Audience profile says are wrong, and gives you a ranked list of stances you can defend. For each one you get the claim, who will disagree, the proof you would need, and the sentence that opens the post.

The ranking matters more than the list. It sorts by how much you personally can back the claim, because a stance you cannot defend in the comments is a liability, not a post.

Why it matters: attention goes to people who are clearly saying something, and around people who are clearly saying nothing.

Prompt to run:

Using my audience profile, build me ten angles for the next two weeks.

For each angle give me:
- The claim, in one sentence, stated plainly enough that someone could
  disagree with it.
- Who disagrees, and their strongest counter.
- The proof I would need to make it credible: a number, a story, or a
  screenshot.
- The opening line of the post.

Rank them by how well I can personally defend the claim, given what I
have actually done. Flag any angle where I would be talking past my
own experience.

Juan’s rule: pick the angle you would still say out loud on a call with a customer. If you would soften it in person, it is not your angle.

4. Skill 3, Draft: your voice at volume

This is the skill everyone tries first and almost everyone sets up wrong. They ask for “a LinkedIn post about X” and get something that sounds like a press release wearing a hoodie.

The fix is to teach the agent your voice from evidence, not adjectives. Give it eight to ten things you actually wrote, including two that performed badly, and ask it to derive the rules itself: sentence length, how you open, how you handle numbers, what you never say. Then it drafts against those rules, and you correct the rules rather than the post.

That last part is the whole trick. When a draft is wrong, do not rewrite the draft. Tell the agent which rule it broke and have it update its own voice file. Fix it once, and every future draft inherits the fix.

Why it matters: an agent drafting in a generic voice creates more work than it saves. An agent drafting in yours creates a first draft you edit in ninety seconds.

Prompt to run:

Here are ten things I have written: [PASTE, include two that flopped].

Derive my voice rules from the evidence, do not describe them in
adjectives. Give me:
- How I open, how I close, and my typical sentence length.
- How I use numbers, names, and specifics.
- Words and constructions I never use.
- What the two that flopped had in common.

Save that as my voice file. From now on, draft against it. When I tell
you a draft is off, update the voice file first, then redraft.

Correct the rules, never the draft.

5. Skill 4, Visual: the brief, not the picture

Your agent should not be making your images. It should be making your image briefs, which is a completely different job and the one that is actually the bottleneck.

The Visual skill takes a finished draft and returns a brief: what the image needs to communicate in one glance, which single number or phrase carries it, what the layout should be, and what must not be in it. It holds your visual system as a file, the same way it holds your voice, so every brief comes out consistent even as the layouts change post to post.

Keep the branding constant and vary the layout. That is the rule that makes a feed look like a brand instead of a mood board.

Why it matters: the post that gets read is the one that survives the half second before the scroll, and that half second is the image.

Prompt to run:

Here is my finished post: [PASTE].
Here is my visual system: [PALETTE, TYPE, LOCKUP, THE RULES THAT NEVER CHANGE].

Write the image brief:
- The one thing the image must communicate in half a second.
- The single number, word, or phrase that carries it.
- The layout: what is the hero element, what supports it.
- What must not appear in this image.

Vary the layout from the last three briefs. Hold every branding rule
constant. Give me the brief, not the picture.

Hold the branding constant and let the layout change.

6. Skill 5, Distribute: one idea, every surface

Most founders write one post and then the idea dies. The idea was the expensive part. The formats are cheap.

The Distribute skill takes one finished idea and cuts it into every surface you publish on: the LinkedIn post, the X version, the newsletter section, the short comment reply you will use twelve times this week. Not copy-paste, which reads badly everywhere. A real rewrite per surface, same claim, different shape.

It also tells you what to do on the surfaces that are not publishing: which ten accounts to reply under this week, and what your reply should add rather than agree with.

Why it matters: reach is mostly a function of how many surfaces one good idea touches before you move on to the next one.

Prompt to run:

Take this idea: [PASTE THE FINISHED POST].

Cut it for every surface, rewritten per surface, never copy-pasted:
1. LinkedIn: the full post, my voice, my structure.
2. X: the same claim compressed, standalone, no thread padding.
3. Newsletter: the section version, with the extra context that did not
   fit anywhere else.
4. Comment: three replies I can use under other people's posts this week
   that add something instead of agreeing.

Then list the ten accounts in my space where this idea is worth showing
up under, and what my reply adds to each.

Cut the idea once, publish it everywhere, and never copy-paste.

7. Skill 6, Capture: turn attention into emails you own

Attention on a platform is rented. The email is yours. Every serious content engine is really an email engine with a public front door.

The Capture skill designs the thing worth trading an email for, and it should come out of the post, not be bolted onto it. If the post argues that most founders build their list backwards, the asset is the list-building checklist. If the post breaks down a workflow, the asset is the workflow file. The agent drafts the asset, writes the gate line, and writes the fulfilment message that delivers it.

The important discipline is that the asset has to be genuinely useful on its own. A gate in front of something thin does not capture an email, it burns a reader.

Why it matters: followers are a number on someone else’s platform. A list is an asset you can still reach next year.

Prompt to run:

Take this week's best-performing angle: [PASTE].

Design the capture asset that falls out of it naturally:
- What the asset is, and why someone would trade an email for it.
- The outline, section by section.
- The one line in the post that offers it.
- The fulfilment message that delivers it and what it invites next.

Rule: the asset must be genuinely useful standing alone. If it only
makes sense as a teaser, tell me and propose a better one.

Build the asset out of the post, never bolted onto it.

8. Skill 7, Learn: the weekly rewrite

This is the skill that separates an agent from a content generator, and it is the one almost nobody sets up.

Once a week the agent reads what actually happened. Not vanity totals. Which angles earned attention, which openings held it, which posts produced captured emails and which produced applause and nothing else. Then it writes the finding back into its own files, the audience profile and the voice rules and the angle criteria, so next week’s drafts start from a smarter place than this week’s did.

Do not skip the part where it writes back. An agent that reports and does not update is a dashboard. An agent that updates is compounding.

Why it matters: everything above gets better on its own, or none of it does.

Prompt to run:

Read everything I published in the last 7 days and what it produced.

Tell me:
- Which angles earned attention, and what they had in common.
- Which openings held people past the first two lines.
- Which posts produced captured emails, separately from which produced
  reactions.
- One thing to stop doing.

Then update my audience profile, my voice file, and my angle criteria
with what you learned, and show me the diff. Do not just report.

Make it write the lesson back into its own files, every week.

9. How one agent runs all seven

Here is the part that matters if you are not technical, and most founders doing their own marketing are not.

You do not build any of this from scratch. Houston is a free desktop app, one click to install. It runs on top of the Claude Code or Codex subscription you probably already pay for, and it connects to the tools you already live in, your CRM, your inbox, your calendar, your files. The seven skills are files the agent keeps and edits, not seven separate products you have to wire together.

That is why the Learn skill works at all. The agent that drafts on Tuesday is the same agent that read Monday’s results and rewrote its own voice rules, because the files sit in one place and persist. A chat window forgets you every time you close the tab.

We are two people running Houston’s marketing, and this is the engine, not a demo of one.

Build it in one agent so the skills can teach each other.

10. Your first week

Build it in this order, paced so you trust each skill before it touches anything public.

→ Day 1: teach Audience and Angle. Give it your customers and your conversations, and let it build the profile and the first ten angles. You end the day with a real list, not a blank calendar.

→ Day 2: teach Draft. Feed it ten things you wrote, including the flops, and let it derive your voice rules. Redraft one old post until it sounds like you, correcting the rules and not the text.

→ Day 3: turn on Visual and Distribute. Take one angle all the way through: post, image brief, X version, newsletter section, ten accounts to reply under.

→ Day 4: build your first capture asset out of your best angle, and publish it with the gate.

→ Week 2: turn on Learn. Let it read the week, write the lessons back into its own files, and show you the diff. This is where the engine starts compounding.

The through-line is the same one across this whole series: let the agent do the machinery, keep the point of view and the publish button in your hands.

The Split

Juan: ship the calendar. The single biggest marketing failure at our stage is not a bad post, it is four weeks of silence because the founder got busy. An agent that reliably puts a decent draft in front of you every morning solves the only problem that actually kills a channel.

Felipe: an agent that never stops shipping will eventually ship something that sounds like nobody. The cost of that is invisible until it is enormous, because your audience does not unfollow you, they just stop reading, and no dashboard shows you that.

Where we land: the agent owns cadence, the human owns conviction. It drafts every day so the channel never goes quiet, and no post goes out without one line in it that only you could have written. If you cannot find that line, the post is not ready.

The bottom line

The marketing agent is one agent you build in Houston and teach seven skills. It learns who you are actually talking to, finds the angle worth defending, drafts in your voice, briefs the visual, cuts one idea across every surface, turns the attention into emails you own, and every week rewrites its own rules from what actually worked.

It runs on the Claude or Codex subscription you already have, connected to the tools you already use. It does the machinery. You keep the stance, the taste, and the publish button.

Build it skill by skill, start with Audience, and never let it publish a post that does not have one line only you could have written.

Marketing was a full time job stacked on top of building the company. The machinery does not have to be.

Build the agent.

Want us to build your marketing agent with you?

You can absolutely build this yourself. Teach the seven skills, feed it your voice, and publish everything in your own words. For most founders, that is exactly the right move, and it is the whole point of this post.

If you would rather have it set up cleanly the first time, we will build it with you. We set up Houston, wire in your CRM and your publishing surfaces, load the seven skills, and tune every prompt to your audience and your voice, so you walk out with a working engine instead of a to-do list.

We take on a small number of founders who want it running in days.

Book a call

Just a quick note before you go

Mission Control is free, every issue. If this one was useful, subscribe and you will get the rest of the series as it ships: the agent builds, the prompt packs, the tools we are actually using in San Francisco this week, and the playbooks we run on ourselves before we ever write them down.

We are building Houston, the desktop app that lets anyone build, connect, and run AI agents across the tools they already use, with no code. The marketing agent in this post is one agent you build on it. Houston is the harness that runs it, and the next hundred agents after it. Build this one now, and the rest of your company’s work, your sales, your ops, your raise, moves onto the same brain later, with your judgment over all of it.

The code to get in is getsh*tdone.

Hope this was valuable.

Cheers, Juan

Houston. AI agents that actually do the work.

Your Next User Is an Agent

Mission Control — Tue, 04 Aug 2026 04:30:15 GMT

Hey everybody, welcome back to Mission Control.

This is what we mean when we say Houston is a harness. Everything in this post is how we build on it ourselves.

Here is the honest fork before we build, because how much you bet on this is a real question and we do not fully agree on it.

By the end of this post, you will have:

→ A clear definition of what “agent-native” actually means, past the buzzword

→ Your product’s jobs written as things an agent can call, not screens a human clicks

→ An engine you can drive from a desktop app, a mobile app, or another agent

→ A state layer an agent can read back to check its own work

→ A human interface that is inspection and override, built last and built fast

→ A distribution plan for the world where agents pick the tools

Here is what is inside.

Table of contents

What actually changes when the user is an agent
The three layers of an agent-native product
Write the jobs, not the screens
Build the engine first, the interface last
Make your product legible: names, errors, permissions
State an agent can read back
Memory, so it gets better at your product over time
The case study: a second product on the same engine
Distribution when agents do the choosing
Your first week

→ Why Your AI Agent Gets Dumber With Every Tool You Add

💭 Remember, the other Mission Control playbooks:

→ The Harness Guide

→ Anatomy of an Agent

→ The Agent Skills Library

→ From 0 to technical founder

→ Your Next User Is an Agent (you are here)

🗣 If you know someone shipping a product this quarter, send them this before they finalise the roadmap. The whole publication is free.

🤖 Shortcut: paste this whole article into Houston and say “audit my product against this, then help me write the job list.”

→ It will turn your feature list into a list of callable jobs

→ It will flag every job that currently only exists as a screen

→ It will draft your agent-facing descriptions and your permission model

→ You finish with a build order, not a manifesto

This post is written to be opened, not just read.

→ Get the app at gethouston.ai

→ The code to get in is getsh*tdone

🚀 Let’s begin!

The tools we use

→ Houston, the harness your product runs on. Free desktop app, open source under MIT.

→ The Houston repo, if you want to read the engine rather than take our word for it.

→ Claude Code or Codex, the model you point at the work. Houston runs on your own subscription.

→ Your own product’s data and services, which is the part nobody can give you.

1. What actually changes when the user is an agent

Start with the honest version, because there is a lot of hand-waving in this space.

Move the meaning out of the interface and into the system.

2. The three layers of an agent-native product

Every agent-native product we have built or taken apart has the same three layers, and confusing them is the most common mistake.

Keep every behaviour below the front door, always.

3. Write the jobs, not the screens

Before you build anything, write the list. Not features. Jobs.

Prompt to run:

Here is my product: [ONE LINE ON WHAT IT DOES AND FOR WHOM].
Here is my current feature list or sitemap: [PASTE].

Convert this into a job list an agent could operate. For each job give me:
- The job name, as a verb phrase.
- One plain sentence on what it does, written for a reader who cannot see
  my interface.
- Inputs it needs, and which ones it can figure out itself.
- What it returns, specifically enough that the caller can verify it worked.
- The failure modes, and what the caller should do about each.
- Whether it may run unattended, needs a human approval, or must never be
  automated at all.

Then flag every job that currently exists only as a screen with no way to
invoke it programmatically. That list is my real backlog.

Write the job list before you write the first component.

4. Build the engine first, the interface last

This is the order, and it is not the order most teams use.

Ship nothing to the screen until the terminal can already do it.

5. Make your product legible: names, errors, permissions

Legibility is the part that separates a product an agent can technically call from a product an agent can actually use well.

Prompt to run:

Here are my job definitions: [PASTE THE JOB LIST].

Act as an agent that has never seen my product and cannot see any screen.

1. For each job, tell me whether the name and description alone are enough
   for you to know when to call it. Rewrite the ones that are not.
2. For each failure mode, tell me whether the error message tells you
   enough to decide between retrying, escalating, and stopping. Rewrite
   the ones that do not.
3. Point out any two jobs you could confuse with each other.
4. Tell me which jobs you would be nervous running without a human, and
   why.

Write for a reader who cannot see anything you built.

6. State an agent can read back

Here is the failure that will bite you hardest in production, and it is not the model being wrong.

This is unglamorous work and it is the difference between a demo and a deployment.

Pair every write with a read, and make repeats safe.

7. Memory, so it gets better at your product over time

A product that an agent uses twice should be easier to use the second time.

Give the agent somewhere durable to keep what it learned.

8. The case study: a second product on the same engine

The test of a harness is not the first product. It is the second one.

Judge the layer by how cheap the second product is.

9. Distribution when agents do the choosing

Now the part that decides whether any of this matters commercially.

Make your product easy to try, safely, without a person.

10. Your first week

Here is the order, paced so you find out early whether your product can survive this.

→ Day 1: write the job list. Every job as a verb phrase with inputs, outputs, failures and a permission level. No code.

→ Day 2: mark every job that today exists only as a screen. That is your backlog, and its length is your honest agent-readiness score.

→ Day 3: take one job all the way. Make it invokable, make its result readable, make its errors specific, make repeats safe. One job done properly teaches you more than ten half done.

→ Day 4: run your core loop from a terminal with no interface open. If you cannot, you have found the real problem, and it is worth the week.

→ Week 2: hand it to an agent cold. Give it only the names and descriptions, no help from you, and watch where it hesitates. Every hesitation is a legibility bug.

The Split

The bottom line

Agent-native does not mean adding a chat box. It means moving every piece of meaning out of your interface and into your system, so that something which cannot see can still do the work.

Do that and your second product costs a weekend instead of a year, and your product gets considered in a world where the thing doing the considering has never looked at your homepage.

Write the job list. That is the whole first step.

Want us to build this with you?

You can do all of this yourself, and the repo is open if you want to read exactly how we did it. For most teams that is the right move.

We take on a small number of teams at a time.

Book a call

Just a quick note before you go

Mission Control is free, every issue. Subscribe and you will get the rest of the series as it ships: the agent builds, the prompt packs, the tools we are actually using in San Francisco this week, and the architecture posts we write only after we have run the thing ourselves.

The code to get in is getsh*tdone.

Hope this was valuable.

Cheers, Felipe & Julian

Houston. AI agents that actually do the work.

The Tool Surface Is a Budget

Mission Control — Sat, 01 Aug 2026 14:01:15 GMT

Hey everybody, welcome back to Mission Control.

Here is the first thing almost everyone does with an agent platform, and it is the thing that quietly ruins the agent. They see the catalog. More than 1,000 tools, one click each. So they connect everything that looks useful, thirty or forty integrations in an afternoon, and then they wonder why the agent got slower, why it picked the wrong tool for a simple job, and why nobody on the team can say what it can actually touch.

I wrote a large part of the engine, so here is the honest version: an agent with every integration switched on is slower and dumber, not smarter. It has too many ways to do the wrong thing.

The fix is a frame, and the frame is the title. The tool surface is a budget. You spend it on the tools your agent touches every day, and you leave the rest off until a job actually needs them. The catalog is not a to-do list. It is the guarantee that when the day comes, connecting tool 21 is a pick from a list instead of an integration project.

Here is the honest fork before we wire anything, because the 1,000+ number cuts both ways.

Felipe’s take: connect generously. Friction is what kills adoption, and an agent that meets you in every tool you use is an agent you actually use. Nobody falls in love with a agent that keeps saying it does not have access.

Julian’s take: every switched-on tool has a price. It rides along in what the model considers on every step, it adds one more lookalike option to pick wrong, and if it can write, it is one more place an error lands. Generosity at the tool layer is how you get a slow agent with a blast radius.

Where we land: the catalog is optionality, the budget is discipline. Wire about 20 tools that cover the five jobs below, scope them tight, and treat everything else as one click away on the day a specific job asks for it. You get the adoption without the sprawl.

By the end of this post you will have:

→ The mechanism: why a bigger tool surface makes a slower, dumber agent
→ The first 20, grouped by the five jobs they do
→ The scope per group: what reads, what drafts, what never writes
→ The wire order, with a smoke test for each group
→ The weekly-use audit that keeps the surface small while the catalog grows

Here is what is inside.

Table of contents

Why more tools make a dumber agent
The budget rule
The first 20, grouped by the job they do
Scopes: reads are cheap, writes are gated
The wire order
One agent, end to end
The weekly-use rule
When to add tool 21

👀 Inside you get:

→ Every deep-dive in this series: the architecture, the exact configs, and what broke on the way
→ Paste-ready agent builds and prompt packs across engineering, GTM, and fundraising
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

💭 As a premium subscriber you also get every other playbook in this series. Recent ones readers open:

1️⃣ The Harness Guide
2️⃣ The Agent Skills Library
3️⃣ Anatomy of an Agent
4️⃣ 55 Prompts for Any Founder —
5️⃣ The GTM Specialist —
6️⃣ The Tool Surface Is a Budget (you are here)

🗣 Or you can always invite a friend and earn rewards along the way:

→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium

Early builders are already inside.

🤖 Shortcut: paste this whole article into Houston and say “wire my first twenty.”

→ It will map the 20 to the tools you actually use
→ It will connect them read-only, in the wire order from section 5
→ It will run the smoke test on each group and show you the results
→ You finish with a 20-tool surface, scoped, and everything else off

This post is written to be opened, not just read.

Run this on Houston

The tool surface in this playbook is Houston’s: one connector layer, more than 1,000 tools, each one a switch you deliberately leave off until it earns its place.

→ Get the app at gethouston.ai
→ The code to get in is getsh*tdone, and the asterisk is part of the code
→ The engine is open source at github.com/gethouston/houston

🚀 Let’s begin!

The tools we use in this article

→ Houston
→ Claude Code or Codex, on the subscription you already pay for
→ Your versions of the 20 in section 3
→ Nothing else. That is the point.

One thing before section one: this article assumes you can switch tools on and off one at a time and scope what each can do. That is how Houston’s connector layer works, so if you want to follow along hands-on, register at gethouston.ai with the code getsh*tdone and open the tool catalog next to this post. If you want to see how the layer is built, the engine is public at github.com/gethouston/houston.

1. Why more tools make a dumber agent

This is not a taste argument. There are three concrete costs, and every switched-on tool pays all three whether or not it is ever used.

Context cost. The agent has to know what it can do. Every enabled tool travels with the agent as one more thing to consider on every single step. Twenty tools is a toolbox. Three hundred is a phone book, and you are paying the agent to re-read the phone book between every action. That is latency and tokens spent on nothing.

Choice cost. Errors scale with lookalike options. If one tool sends a team chat message and another sends an email and a third posts a comment, “tell the team” now has three plausible answers and two of them are wrong for this job. An agent picking from five tools commits. An agent picking from three hundred deliberates, and deliberation is where the wrong path gets taken.

Blast radius. Every tool that can write is a place a mistake can land. A wrong read costs you nothing but time. A wrong write is a sent message, a changed record, a triggered deploy. Forty writable tools is forty doors you now have to think about. Nobody audits forty doors. Everybody can audit ten.

Notice what is not on the list: capability. Switching on tool number 200 does not make the agent more capable at the jobs it does daily. It makes those jobs slightly slower and slightly less reliable, in exchange for coverage of a job that has not shown up yet.

Count the costs before you count the features.

2. The budget rule

So treat the surface like a budget, because that is what it behaves like.

The rule has three parts. Spend the budget on tools the agent touches every day, the ones wired into the work it actually does. Hold the rest at zero, not because they are useless but because they are not earning anything today. And when a real job shows up that needs a new tool, spend deliberately: connect it, scope it to that job, and let the weekly-use rule in section 7 decide if it stays.

The posture underneath is default-deny. The agent sees the narrowest set of tools its current work needs, never the whole catalog. This is the same principle that runs through every skill file we publish: the Tools block is a permission boundary, not a suggestion. The catalog exists so that granting is cheap. The budget exists so that granting is deliberate.

One number worth writing down before you wire anything: how many tools are on right now, and when each was last used. If you cannot answer, that is the first finding.

Decide the budget before you open the catalog.

3. The first 20, grouped by the job they do

Here is my first wire, grouped by the five jobs an agent does for a working team. The post named three per group. The full set is four, because the fourth in each group is the one people forget and then miss in week two.

SOURCE AND CODE
  the repo              read code, open PRs, never merge
  the issue tracker     read and file, comment, never close others' work
  the CI checks         read results, re-run, never override
  the package registry  read versions and advisories, never publish

COMMS
  the inbox             read and draft, never send
  the team chat         read and draft, post only where invited
  the calendar          read, propose holds, never move others' events
  the meeting recorder  read transcripts, never share them

KNOWLEDGE
  the docs              read and draft edits
  the wiki              read and draft, never restructure
  the file store        read, write only to its own folder
  the design files      read and comment, never edit

CUSTOMER
  the CRM               read, draft updates, never bulk-edit
  the support queue     read, draft replies, never send or close
  the product analytics read only
  the billing system    read only, always

OPS
  the deploy target     read state, never trigger
  the error tracker     read, link, annotate
  the on-call rotation  read, page only through the human gate
  the metrics store     read only

That is 20. Five jobs, four tools each, and the scope column matters as much as the name column, which is section 4.

Map each line to your stack: your repo host, your tracker, your chat, your CRM, whatever they are. The names change per company. The jobs do not.

Wire the jobs, not the logos.

4. Scopes: reads are cheap, writes are gated

Look back at the list and notice the pattern in the right-hand column. It is one rule applied twenty times.

Reads are cheap. Letting the agent see the repo, the queue, the metrics, and the calendar costs you almost nothing and buys you everything: grounded answers instead of guesses. Grant reads freely inside the twenty.

Drafts are the default write. Almost every write the agent makes should produce something a human approves: a draft reply, an open PR, a proposed calendar hold, a suggested CRM update. The work gets done; the commit stays yours.

Some writes are never. Merging to main. Sending anything to a customer. Triggering a deploy. Paging a human. Publishing a package. Touching billing. These stay behind a human gate permanently, not until you trust the agent more. Trust is not the variable. Reversibility is.

Two more habits that make the scopes real. Give the agent read replicas and views where they exist, never the primary. And keep secrets out of the surface entirely: an agent does not need credentials it can leak, it needs a harness that holds them, which is the argument of The Harness Guide and the reason the engine executes actions with keys the model never sees.

Write the never-list before the first connection.

5. The wire order

Order matters because trust builds in one direction. Wire the groups from least dangerous to most, and smoke-test each before the next.

→ First, source and code. Lowest stakes, highest daily value for a technical team, and every write is already a reviewable artifact. Smoke test: “summarize the last five merged changes and name the open issue each one touches.”
→ Second, knowledge. Pure read value. Smoke test: “find the doc that defines our refund policy and quote the exact rule.”
→ Third, comms. Read plus drafts. Smoke test: “what is on my calendar today, and which unread email actually needs me first?”
→ Fourth, customer. Real records now, so drafts only. Smoke test: “pull the five newest support tickets and match each to its account and plan.”
→ Fifth, ops. Highest stakes, reads only to start. Smoke test: “what shipped in the last deploy, and did the error rate move in the hour after?”

Each smoke test has the same shape: a question that forces the agent to actually use the group, with an answer you can check yourself in the source tool. If the answer is wrong, fix the connection or the scope before adding the next group. A wrong answer on day one is a configuration problem. The same wrong answer in week three is an incident.

One group per sitting. Twenty minutes each. Done inside a day, verified inside a day.

Wire in order, and check each rung before the next.

6. One agent, end to end

Here is what the 20-tool surface already covers, and why I hold the line that everything else can wait. Three workflows, each crossing several groups, none needing tool 21.

The morning triage. Error tracker plus deploy state plus on-call plus team chat: when something broke overnight, the agent reads the alert, correlates it against what shipped, and posts a ranked list of likely causes in the channel before anyone opens a laptop. Reads all the way through, one gated post at the end.

The PR loop. Repo plus CI plus issue tracker: first-pass review on every pull request, style and obvious bugs and the missing test, linked back to the issue it closes. It comments; a human clicks the button. The write is a comment, the merge is never.

The customer picture. Support queue plus CRM plus analytics plus docs: every new ticket matched to its account, usage pulled, the relevant doc found, a reply drafted with the source cited. The reply waits for a person; the CRM update is a proposed edit, not a landed one.

Notice the shape shared by all three: many reads, few writes, every write either reviewable or gated. That is not a limitation of the setup. That is the setup.

If your agent cannot do these three with 20 tools, the problem is not missing tools.

7. The weekly-use rule

The budget only holds if something enforces it, and the enforcement is one rule plus one habit.

The rule: a tool earns its place when the agent uses it weekly. Not “might need it”, not “took an afternoon to connect so it stays.” Weekly use, for real work, or it goes back off. Switching off is one click and completely reversible, which is exactly why the rule is cheap to hold and sprawl is not.

The habit is a monthly audit, and the agent runs it on itself:

Run the tool surface audit. List every connected tool with the last time you used it and for what job. Propose switch-off for anything unused in 14 days. List every tool you reached for and did not have, with the job that wanted it. End with the numbers: how many on, how many off, and the three scopes you would tighten if it were your call.

Read the output, switch off what fell idle, and note the candidates for a real add. The surface breathes: it grows when jobs demand and shrinks when they stop, and the audit is what keeps the direction honest.

The metric that matters is not how many tools are connected. It is what fraction of the connected tools worked this week. Twenty of twenty beats forty of one hundred every time anyone has measured anything.

Audit monthly, prune without sentiment.

8. When to add tool 21

Some day a job shows up that the twenty do not cover. Good. That is what the other 980 are for. The discipline is in how it comes in:

→ Name the job first. “Connect the data warehouse” is not a job. “Answer revenue questions from the warehouse every Monday” is
→ Connect read-only, scoped to that job, and nothing else
→ Run it for two weeks inside the job that asked for it
→ Apply the weekly-use rule. If the job was real, the tool stays. If it was a maybe, it goes back off, one click, no ceremony

That is the whole lifecycle: tools enter through a job, survive through use, and leave through the audit. The catalog makes entering cheap. The budget makes staying earned.

And that is the real answer to “which integrations should I set up?” Wrong question. The right question is which jobs run weekly, and the twenty above are where that answer starts for almost every team I have watched wire this up.

Add tools the way you add dependencies: reluctantly, and pinned to a reason.

The bottom line

More than 1,000 tools is the reason you never build an integration again. About 20 is the number you should actually have on. Every switched-on tool costs context, adds a wrong path, and widens the blast radius, so spend the surface like the budget it is: five jobs, four tools each, reads cheap, drafts default, the irreversible stuff never, wired in order and smoke-tested as you go.

Then hold the line with one rule: a tool earns its place when the agent uses it weekly, and a monthly audit the agent runs on itself keeps everyone honest. Everything else in the catalog stays one click away for the day a real job asks.

A smaller surface is a sharper agent. Wire your twenty this week.

Want us to wire your tool surface with you?

You can do this yourself: register, open the catalog, wire the five groups in order, and run the audit monthly. For most technical teams that is exactly the right move, and it is the whole point of this post.

If you would rather have it set up cleanly the first time, we will do it with you. We map the 20 to your actual stack, connect them with the scopes set the way section 4 says, run the smoke tests with you, write your never-list, and schedule the monthly audit, so you walk out with a scoped, working surface instead of a catalog hangover. We take on a small number of teams who want it running in days.

Just a quick note before you go! This is what your premium subscription gets you, every month:

Early builders are already inside. You are in good company.

We are building Houston, the open harness for AI agents. The engine is Rust, frontend-agnostic, driven over HTTP and WebSocket; one core runs the Tauri 2 desktop app, the mobile companion, and any custom frontend you point at it. It is model-agnostic and runs on the subscription you already pay for, your Claude Code, your Codex, so there is no lock-in to a provider whose pricing you do not control. The tool layer in this post is that engine’s connector layer, built on Composio’s toolkit protocol, which is how the catalog reaches more than 1,000 tools without a thousand hand-rolled integrations, and why the budget in this post is a set of switches instead of a backlog. SmartBooks, a separate product with its own brand and zero shared UI, runs on the same engine in about 400 lines, which is the cleanest proof I can offer that the layer is real. It is open source under MIT: read the engine at github.com/gethouston/houston and point an AI at it to check me. 1,500 builders across 46 countries are already inside, and 45% come back every week. Register at gethouston.ai with the invite code getsh*tdone. Type it exactly, the asterisk is part of the code.

Hope this was valuable.

Cheers,
Julian

Houston. AI agents that actually do the work.
Mission Control. Building with AI, from Silicon Valley.

55 Prompts for Any Founder

Mission Control — Wed, 29 Jul 2026 08:13:02 GMT

Hey everybody, welcome back to Mission Control.

Here is a founder’s week, measured honestly. Forty minutes turning a messy call into a follow up. An hour on the investor update. Two hours building a target list nobody ends up contacting. A job post copied from a template that attracts the wrong people. A board meeting that turns into a plan in your head and nowhere else.

None of that is the company. All of it eats the week.

The slow way is doing those jobs by hand, one tab at a time, every week, forever. The fast way is a prompt that does the whole job, start to finish, and shows you the result for a yes or a no.

That is what this post is. 55 prompts I run my company on. Fundraising, sales, hiring, ops, and the AI work most founders still do by hand. Not 55 clever one-liners. 55 prompts that each do a real job, tested on a real company that is raising, selling, and shipping right now. The six you saw on LinkedIn are all here, with the other 49.

Here is the honest fork before we start, because prompt packs have a reputation and some of it is earned.

Felipe’s take: a founder should run the company on prompts from day one. Every hour you spend doing a job a prompt already does is an hour the company paid too much for. Take working prompts, run them, move.

Julian’s take: 55 prompts you paste blind are 55 ways to ship something you did not check. The prompt is the easy part. The judgment on the output is the job, and no pack does that part for you.

Where we land: run the pack, keep the yes. Every prompt in this post produces a draft, a list, or a plan that waits on your approval before anything sends, logs, or publishes. The prompts do the work. You stay the founder.

By the end of this post you will have:

→ All 55 prompts, paste-ready, sorted by the job they do
→ The first five to run this week, picked by what your company needs right now
→ Every output gated on your yes before anything sends or logs
→ The three prompts worth putting on a schedule, so the work runs while you sleep

Here is what is inside.

Table of contents

How to run these prompts
Fundraising: 12 prompts that run the raise
Sales: 11 prompts that fill and move pipeline
Hiring: 8 prompts that build the team
Ops: 14 prompts that run the company
AI workflows: 10 prompts that make the whole thing compound
Your first week

👀 Inside you get:

→ Paste-ready agent builds and prompt packs across fundraising, sales, and GTM
→ The latest tools and updates for building with AI, no code required
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

💭 As a premium subscriber you also get every other playbook in this series. Recent ones readers open:

1️⃣ The AI Agent That Runs Your Entire Raise
2️⃣ 40 Prompts That Run Your Entire Outbound
3️⃣ The VC’s Agent Stack
4️⃣ Your Go-to-Market Is Running on 12 Disconnected Tools
5️⃣ 55 Prompts for Any Founder (you are here)

Early founders are already inside.

🤖 Shortcut: paste this whole article into Houston and say “load these 55 prompts and set up my founder stack.”

→ It will save all 55 as reusable prompts, sorted by job
→ It will ask what you are working on this week and pick your first five
→ It will run them with you, every output waiting on your yes

This post is written to be opened, not just read.

Run these prompts on Houston

Every prompt in this pack runs inside Houston, the desktop app where AI agents work across your CRM, inbox, calendar, and files, on your own model subscription and your own machine.

→ Get the app at gethouston.ai
→ The code to get in is getsh*tdone

🚀 Let’s begin!

The tools we use in this article

→ Houston
→ Claude Code or Codex, on the subscription you already pay for
→ Your CRM, email, and calendar
→ Your call recorder and your job board, when a prompt reaches for them

One thing before prompt one: these are written to run inside Houston, so the agent can actually reach your tools. Open gethouston.ai, download the app, and enter the code getsh*tdone. Two minutes, and every prompt below stops being text and starts being work.

1. How to run these prompts

Three things before you paste anything, so the pack works on day one.

First, run them inside Houston. It is a free desktop app, one click to install, and it is what turns these from text into work: the agent behind the prompt can read your CRM, your inbox, your calendar, and your files through connectors, so “pull my pipeline” actually pulls your pipeline. On your own model subscription and your own machine. Connect read-only first, widen only when a prompt needs it.

Second, the brackets are yours. Every [bracket] in a prompt is a placeholder for your specifics. Fill them, or just paste the prompt as is and let the agent ask you for what is missing. Both work.

Third, the yes gate is not decoration. Every prompt here ends the same way: the output waits on your approval. Nothing sends, nothing logs, nothing publishes on its own. Keep that line in when you adapt them. It is the difference between an agent that works for you and one you have to clean up after.

Where to start, by what your week looks like:

→ Raising right now: prompts 1, 3, 8, 9, and 12
→ Selling right now: prompts 13, 14, 16, 17, and 19
→ Hiring this quarter: prompts 24, 25, 26, 29, and 31
→ Drowning in ops: prompts 33, 34, 36, 39, and 41

Pick your five before you read on.

2. Fundraising: 12 prompts that run the raise

The raise is a pipeline, and every stage of it has a prompt. These twelve cover the list, the first email, the meeting, the follow up, and the update that keeps you warm between rounds.

1. The investor update that wins back passes

Here are this month's numbers and last month's update: [paste both]. Draft this month's investor update. Open with the number that moved most, then three wins, one honest miss with the fix, and one specific ask. Under 400 words, in my voice, ready to send. Show me the draft first.

This is the one that makes the investors who passed lean back in. Consistency is the trick. The update that arrives every month, on time, with an honest miss in it, does more than any deck.

2. The narrative pressure test

Here is my current pitch narrative: [paste]. Argue against it like a partner at a fund that passes on 99 of 100 deals. List the five weakest claims, the question each one invites, and a stronger version of each claim using only facts I gave you.

3. The target list

Search for 30 investors who lead [stage] rounds in [sector], check size [range], active in the last 12 months, [geography] first. For each, give me the fund, the right partner, and one line on why this deal fits their thesis. Rank by fit, not by fame.

4. The cold first email

For each investor on this list: [paste]. Read their thesis and recent investments, then draft a four sentence first email: one line that proves I know what they fund, one line on what we are, the metric that earns the meeting, and a specific ask. No adjectives doing the work numbers should do. Drafts only, I send.

5. The warm intro pack

Cross-reference this investor list with my LinkedIn connections and my inbox: [paste list]. For each investor, find the strongest mutual contact, then draft the forwardable blurb: three sentences the mutual can send in one click. Show me the pack before anything goes out.

6. The pass decoder

Here are the last [N] pass emails: [paste]. Cluster the real reasons behind the polite language and count them. Split them into what we fix, what we answer better, and what we ignore. Then draft the one change to the deck that addresses the top cluster.

7. The data room builder

List everything a [stage] data room needs, grouped by folder. Check it against what I have here: [connect the folder]. Flag what is missing, draft the missing one-pagers from the numbers I gave you, and mark every figure you could not verify with [CONFIRM].

8. The meeting-prep brief

I meet [investor, fund] on [date]. Pull their portfolio, their thesis, and anything they published in the last six months. Give me one page: how we fit the thesis, the three questions they will ask, my strongest answer to each, and the one thing not to say.

9. The same-day follow up

Here is the transcript of today's pitch: [paste]. Draft the follow up: thank them in one line, answer the two hardest questions better than I did live, attach what they asked for, and propose the next step with a date. My voice, waiting on my yes.

10. The metrics one-pager

Take these numbers: [paste]. Build the one-page metrics snapshot investors expect at [stage]: growth, retention, unit economics, runway. Plain numbers, no adjectives, and a one-line footnote on how each number is calculated.

11. The term reader

Here is the [SAFE / term sheet]: [paste]. List every term that deviates from standard terms, what each deviation costs me in plain language, and the questions to ask before I sign. This is preparation for my lawyer, not a replacement for one.

12. The gone-quiet nudge

Check my inbox and CRM against my active investor list. Who went quiet for 14 days or more after a real conversation? For each, draft a three sentence nudge with one new proof point from this month. Drafts wait for my yes.

Send the update first. Everything else in a raise gets easier when the update habit exists.

3. Sales: 11 prompts that fill and move pipeline

Sales prompts earn their keep twice: once on the work, once on the CRM staying true without anyone typing into it.

13. The call-to-CRM pipeline

Here is the raw transcript: [paste]. Give me three things: the follow up email in my voice, the action items with owners and dates, and the CRM update for this deal, stage, next step, close date. Show me all three. Log the CRM update only after my yes.

The messy-transcript prompt from the post. One paste replaces the 40 minutes after every call.

14. The ICP twenty

Pull 20 accounts that fit this ICP: [industry, size, signal]. For each, find the right contact, one line on why now, and draft a first message that references something true about them this quarter. I review every draft before anything sends.

15. The pricing pressure test

Here is my pricing: [paste]. Attack it like a procurement lead with a budget freeze. List the five pushbacks I will hear, the answer to each, where I am leaving money on the table, and the one change that raises average deal size without losing the mid-market.

Run this before a customer runs it on you.

16. The objection bank

Read the last [N] call transcripts. List the top ten objections in the prospects' actual words, ranked by frequency, and for each write the answer that worked in a call where the deal moved anyway. Format it as a card I can keep open while I sell.

17. The stale-deal sweep

Find every deal idle for 21 days or more. For each: the last real signal, the likely reason it stalled, and a next touch that is not a check-in. Queue the drafts for my review.

18. The demo-to-proposal

Here is the demo transcript: [paste]. Draft the proposal: their problem in their words, the scope we showed, pricing per our sheet, and a close plan with dates. One page. Waiting on my yes.

19. The Monday pipeline read

Read my CRM. What moved last week, what stalled, which three deals decide this quarter, and where should my selling hours go this week? One page, numbers first.

20. The champion one-pager

My champion at [account] needs to sell this internally. From our thread and the transcript, draft the one-pager their boss will actually read: the problem, the cost of doing nothing, what we do, the price, and a two-line summary the champion can paste into an email.

21. The competitor save

The prospect at [account] named [competitor]. Build the honest comparison on the dimensions that matter for their use case: where the competitor is genuinely better, where we are, and the reply that reframes the decision without trash talk. Draft it for my review.

22. The case study builder

Take the closed-won deal with [account] and pull the thread and the notes. Draft the case study: the before, the rollout, the numbers after, and the quote to request. Add three one-line proof points for outbound. Flag anything that needs the customer's permission.

23. The inbound triage

Here are this week's inbound leads: [connect the form or paste]. Score each against my ICP, split them into book now, nurture, and pass, and draft the right reply for each pile. Nothing sends without my yes.

Start with the transcript prompt. It pays for the whole pack in a week.

4. Hiring: 8 prompts that build the team

Hiring is the most expensive thing a founder does on vibes. These eight put structure around it without slowing it down.

24. The hiring kit

I am hiring a [role]. Draft three things: the job post without buzzwords, the scorecard with five must-haves and the evidence for each, and eight first-round questions mapped to the scorecard, with what a strong answer and a weak answer sound like.

The job post, the scorecard, and the first-round questions from one prompt. Every later hiring prompt hangs off this scorecard.

25. The resume screen

Score these resumes against the scorecard: [paste both]. Rank them, give me two lines per candidate on evidence found and evidence missing, and flag anyone I would wrongly filter out because their path is non-standard.

26. The interview debrief

Here are the panel's notes: [paste]. Score the candidate against the scorecard per interviewer, surface where we disagree and what evidence would settle it, and recommend advance or pass with the reason in one sentence.

27. The offer note

Draft the offer message for [candidate]: the role, the comp with how we set it, the equity in plain numbers they can actually compute, why them specifically, and the deadline. Warm, precise, no pressure theater.

28. The 30-day plan

Draft the first 30 days for the new [role]: week by week, what they own, who they meet, and the one deliverable that proves the hire by day 30. Fit it to what you can see of our stack and calendar.

29. The reference script

Write my reference-call script for [candidate, role]: eight questions that surface real signal instead of politeness, including past-behavior versions of my two biggest doubts from the debrief.

30. The sourcing opener

Find [N] candidates who match this scorecard: [paste]. For each, one line on the specific work that qualifies them, and a two sentence opener about that work, not about us. Drafts wait for me.

31. The role-or-not test

Before I open this req, here is the work piling up: [describe]. Split it into what a prompt in this pack already does, what a contractor covers, and what actually needs a full-time [role]. Give me the call and the math.

Run the role-or-not test before the job post. Some reqs dissolve.

5. Ops: 14 prompts that run the company

Ops is where founder weeks go to die, because every task is small and none of them stop coming. These fourteen are the standing army.

32. The board-to-plan converter

Here is the last board deck and the meeting transcript: [paste]. Turn them into next quarter's plan: the three commitments we made, the owner of each, the numbers that prove each one, and the weekly check. One page, ready to share with the team.

Your last board meeting, turned into next quarter’s plan instead of a memory.

33. The Monday brief

Every Monday at 7: read my calendar, inbox, and CRM. One page: the three decisions this week actually needs, the three numbers that moved, and what I said I would do last week that is still open.

34. The decision log

Here are this week's meeting notes: [connect or paste]. Extract every decision made, the owner, and the date, then list the open questions nobody closed. Append it to my decision log and show me the diff.

35. The team update

Draft Friday's team update from what actually happened this week: shipped, slipped, learned, next. Pull from the tools, keep it honest, keep it under 300 words, my voice. I edit before it posts.

36. The burn read

Here is the bank feed and payroll: [connect or paste]. Current monthly burn, runway at today's spend, the three biggest line items trending up, and one cut per item with what that cut costs us. Numbers first, then the memo.

37. The contract sweep

Go through these vendor agreements: [connect the folder]. List every auto-renewal and its date, the notice window to cancel each, and the three contracts most worth renegotiating. Put the notice deadlines on my calendar as drafts.

38. The SOP writer

Here is how I did [task] this time: [paste the steps or the transcript]. Turn it into an SOP anyone on the team can run: numbered steps, the checks, the failure points, and what done looks like. Save it where the team will find it.

39. The inbox pass

Go through my unread inbox. Sort it into needs me, delegate, and archive. Draft replies for the first two piles in my voice, flag the three emails with real money or real risk in them, and send nothing.

40. The one-view numbers

Pull [metrics] from [tools] into one weekly view: this week, last week, the trend, and one line on what changed. Same format every week, so anomalies jump out.

41. The unblocker

Scan the project board. What has not moved in a week, who owns it, and what is it waiting on? Draft the specific unblocking nudge for each owner, not a status request. My yes before they go.

42. The policy drafter

Draft our [travel / refund / remote] policy: one page, plain language, the five cases that actually come up with the answer for each, and a line on where judgment beats the rule. Mark anything that needs legal review.

43. The support triage

Read this week's support tickets: [connect or paste]. Cluster the issues, rank them by frequency times severity, list the top three fixes with owners, and draft replies for the top cluster in our voice.

44. The OKR check

Here is the quarter plan: [paste]. Against what the tools show actually happened, score each objective red, yellow, or green with the number that says so, and recommend the one thing to drop so the top priority makes it.

45. The decision memo

I need to decide [decision] by [date]. Draft the one-page memo: the options, the tradeoffs in numbers where numbers exist, how reversible each path is, your recommendation, and what would change it.

Put the Monday brief in first. It is the prompt that makes you want the other thirteen.

6. AI workflows: 10 prompts that make the whole thing compound

This is the category most founders still do by hand: the work of running the AI itself. These ten turn one-off prompts into a stack that gets better every week.

46. The prompt upgrader

Here is a prompt I keep using: [paste]. Rewrite it to do the whole job: the inputs it should ask for, the exact output format, the checks before it finishes, and the review gate before anything sends. Return it paste-ready.

47. The skill builder

I run this prompt every week: [paste]. Package it as a reusable skill: a name, the inputs it collects, the steps, the output format, and the approval step. Save it so I can run it by name.

48. The connection audit

List the tools connected right now, and the tools this pack keeps reaching for that are not. For each missing one, tell me what connecting it unlocks from these 55 prompts, in order of payoff. Then connect the top one with me, read-only first.

49. The scheduler

Take [prompt name] and put it on a schedule: [cadence]. It runs, produces the draft or the digest, and waits. Nothing it makes sends, logs, or publishes without my yes. Show me the first run before the schedule goes live.

50. The gatekeeper

Audit every scheduled run and skill I have. For each, show me what it can read and what it can write. Flag anything that can send or change records without an approval step, and add the gate.

51. The workload router

Look at the jobs I run most from this pack. Tell me which ones need the heavy model and which run fine on the light one, and set the defaults so the quality stays and the subscription lasts the month. Explain the two routings that matter most.

52. The morning transcript run

Every morning: take yesterday's call recordings, and for each produce the summary, the action items with owners, and the draft CRM update. Queue everything for my yes with coffee. Read-only until I say otherwise.

53. The repurposer

Take this: [paste the asset]. Turn it into a LinkedIn post in my voice, a three line version for email, and a thread. Same idea, native to each format, no hashtags doing the work. Drafts side by side, I pick.

54. The voice loader

Read my last 20 posts and 20 sent emails. Build my voice profile: sentence length, how I open, the words I never use, how I close. Save it as the default so every draft from this pack sounds like me on a good day.

55. The weekly agent report

Every Friday: what did my prompts and scheduled runs produce this week, what did I approve, what did I edit most, and what does that say I should automate next, or stop automating? One page. This is how the stack compounds.

Run the voice loader early. Every other prompt gets better the day it exists.

7. Your first week

Here is the split on how far to push the automation, because we disagree in the office too.

Felipe’s take: schedule everything that repeats. The whole point is the work running while you sleep. A prompt you have to remember to run is half a prompt.

Julian’s take: schedule nothing you have not run by hand five times. An unread digest is noise. An unreviewed send is a liability with your name on it.

Where we land: manual first, schedule what you stopped editing. Run your five by hand this week. The ones whose output you approve without touching, put on a schedule with prompt 49. The ones you still rewrite, keep manual until you do not. Sends stay human either way.

The week, paced so you trust it:

→ Day 1: install Houston with the code getsh*tdone, connect your CRM, email, and calendar read-only, and run the voice loader (54)
→ Day 2: run your five, picked from the map in section 1. Approve, edit, or kill each output, and notice which was which
→ Day 3: run the transcript prompt (13) on your next call the hour it ends
→ Day 4: fix your favorite rough prompt with the upgrader (46), and save your most-used one as a skill (47)
→ Day 5: schedule the Monday brief (33) and the morning transcript run (52), then run the gatekeeper (50) over what you built
→ Friday next week: run the weekly agent report (55) and let it tell you what to automate next

That is the whole build. Five prompts by hand, two on a schedule, every output waiting on your yes.

The bottom line

You do not need 55 tabs, a productivity system, or a chief of staff to stop doing the work that eats founder weeks. You need working prompts with real jobs, connected to the tools your company already runs on, gated on your approval.

That is what this pack is. The raise runs on twelve. Pipeline runs on eleven. Hiring on eight, the company on fourteen, and the stack itself on ten. Tested on a real company that is raising, selling, and shipping right now, on our own model subscription and our own machines.

The work that used to eat your week now runs while you sleep. You read the outputs with coffee and say yes.

Pick your five and run them today on Houston. The code to get in is getsh*tdone.

Want us to load your founder stack with you?

You can do this yourself: install Houston, connect your tools read-only, and run the pack. For most founders that is exactly the right move, and it is the whole point of this post.

If you would rather have it set up cleanly the first time, we will do it with you. We install Houston on the right path, connect your CRM, email, and calendar with the scopes set safely, load all 55 prompts, tune the five that fit your week, and schedule the ones you approve, so you walk out with a running founder stack, not a to-do list. We take on a small number of founders who want it running in days.

Just a quick note before you go! This is what your premium subscription gets you, every month:

Early founders are already inside. You are in good company.

We are building Houston, the desktop app that lets anyone build, connect, and run AI agents across the tools they already use, with no code. The 55 prompts in this post are the founder stack you run on it. Houston is the harness that runs them, and the next hundred agents after them.

Load the pack now, and the rest of your company’s work moves onto the same brain later, with your judgment over all of it. 1,500 builders across 46 countries are already inside, and 45% come back every week. Houston is invite-only until we open to the public.

Get it at gethouston.ai. The code to get in is getsh*tdone.

Hope this was valuable.

Cheers,
Felipe

Houston. AI agents that actually do the work.
Mission Control. Building with AI, from Silicon Valley.

The GTM Specialist

Mission Control — Tue, 28 Jul 2026 14:15:12 GMT

Hey everybody, welcome back to Mission Control.

Meet Sofia. B2B SaaS, 40k MRR, doing all of the marketing herself between everything else, and convinced the fix was a job post she kept not writing. Forty-three days after she stopped believing that, the picture looked different: one AI operator running her go-to-market, three channels live, qualified pipeline up 4.2x. The marketing hire never happened.

Not because an operator is magic. Because she fixed the order of operations.

Here is how the first marketing hire usually goes. You feel the growth ceiling, you write a job post, you interview for eight weeks, you pay a recruiter, and someone talented shows up on a Monday with one question you cannot answer cleanly: what is the positioning, who exactly do we sell to, what has already been tried?

So they spend their first two quarters assembling that answer. The positioning doc. The ICP. The channel history. The voice. Work that was never a marketing hire’s job, because all of it lives in one head: yours.

Most pre-Series-A founders think the next marketing hire is the unlock. It is the bottleneck. Before any marketer ships work worth shipping, someone has to write the brief, and that someone is the founder. Most founders skip it, hire too early, and pay for a year of someone slowly writing the brief that should have existed on day one.

The GTM Specialist flips the order. It forces you to write that brief on day one, then runs the work the same afternoon. Five jobs, one operator, built in about two hours, with output you can ship before dinner.

Here is the honest fork before we build, because “do not hire a marketer” is not actually the claim.

Felipe’s take: founders hide from marketing behind hiring. Writing the positioning feels hard, so they outsource it to a job post. You cannot delegate the brief. Run the operator, own the answers, and hire from strength later.

Juan’s take: a great early marketer compounds like nothing else, and no operator replaces taste. But a great marketer landing in a company with no brief spends six months excavating it. The hire is not wrong. The order is wrong.

Where we land: brief first, loop second, hire third. The operator forces the brief into writing on day one and runs the five jobs from it. When volume outgrows you, you hire, and that person walks into a running system with the brief already on paper. Same conclusion Sofia reached, and we will get to her numbers.

And if you ran last week’s 55 Prompts for Any Founder [swap in the live URL], you already felt this: the marketing prompts in that pack are single jobs. Today we promote them into one operator that owns the whole loop.

By the end of this post you will have:

→ The operator brief written: identity, scope, voice, constraints
→ The six-file fact pack that grounds every recommendation
→ All five jobs running, with a paste-ready prompt for each
→ The three operating loops on a schedule: Monday plan, daily triage, monthly retro
→ The full paste-ready operator definition, ready to run inside Houston

Here is what is inside.

Table of contents

The bottleneck nobody budgets for
The operator brief: identity, scope, voice, constraints
The six-file fact pack
The five jobs it owns
The three operating loops
Connect it to your stack
The paste-ready operator definition
The seven-day rollout

👀 Inside you get:

→ Paste-ready agent builds and prompt packs across GTM, outbound, and fundraising
→ The latest tools and updates for building with AI, no code required
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

💭 Recent ones readers open:

1️⃣ 55 Prompts for Any Founder — [swap in the live URL, publishes right before this one]
2️⃣ Your Go-to-Market Is Running on 12 Disconnected Tools
3️⃣ The AI Agent That Runs Your Entire Raise
4️⃣ 40 Prompts That Run Your Entire Outbound
5️⃣ The VC’s Agent Stack
6️⃣ The GTM Specialist (you are here)

🗣 Or you can always invite a friend and earn rewards along the way:

→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium

Early founders are already inside.

🤖 Shortcut: paste this whole article into Houston and say “stand up my GTM Specialist.”

→ It will interview you to write the operator brief
→ It will build the six-file fact pack from your answers
→ It will load the five jobs and the three loops, and run the first Monday plan the same day, waiting on your yes

This post is written to be opened, not just read.

Run the GTM Specialist on Houston

The operator in this playbook runs inside Houston, the desktop app where AI agents work across your CRM, analytics, ad platforms, and inbox, on your own model subscription and your own machine.

→ Get the app at gethouston.ai
→ The code to get in is getsh*tdone

Access Houston

🚀 Let’s begin!

The tools we use in this article

→ Houston
→ Claude Code or Codex, on the subscription you already pay for
→ Your CRM, analytics, and ad platforms
→ Your email and calendar
→ Your lead sources, wherever inbound lands

One thing before we start: this playbook is written to run inside Houston, so the operator can actually read your CRM and your numbers instead of guessing. Open gethouston.ai, download the app, and enter the code getsh*tdone. Two minutes, and everything below stops being a document and starts being an operator.

1. The bottleneck nobody budgets for

Run the numbers on the hire you are about to make. A first marketing hire at a pre-Series-A company costs roughly USD 60,000 a year and up, takes two months to find, and ramps for two quarters. Best case, you get real output in month five. And the first thing that person needs, before a single campaign, is the brief: positioning, ICP, channel state, voice. Information only you have.

The GTM Specialist costs USD 20 to 200 a month, the price of the model subscription you already pay for. It ramps in hours. And it starts by forcing the brief out of your head and into files, because it refuses to work without them.

Three things change when the brief lives inside an operator instead of a hire:

→ The strategy stays editable. Change your positioning and the operator works from the new version the same minute, with no re-onboarding and no drift between what you think and what ships
→ Nothing waits on ramp. The operator reads the fact pack and starts producing the same afternoon you write it
→ The hire decision becomes an experiment. Thirty days of the loop shows you what an operator covers and what genuinely needs human judgment, and that second list is your job description if you still want one

Back to Sofia. Forty-three days on the loop: three channels launched, 47 ad variants tested, 2,300 leads scored, 180 sales emails drafted, and the 4.2x lift in qualified pipeline. She did not need a marketing hire. She needed a part-time producer to ship the ads the specialist had already briefed.

That is a USD 60,000 decision made by running the loop, not by reading job boards. Maybe you do need the hire. But now the question has data: run the loop for a month, see what only a human could have done, and hire for exactly that.

Write the brief before you write the job post.

2. The operator brief: identity, scope, voice, constraints

The difference between a chatbot that talks about marketing and an operator that runs it is the brief. Four parts, all of them short, all of them yours.

Identity. Who the operator is: a senior GTM operator for your company, at your stage, with opinions. Not an assistant, not a brainstorm partner. An operator that owns outcomes and tells you when a plan is weak. The identity sets the posture: a named role with a bias toward shipping produces sharper recommendations than a generic assistant, and it stops hedging.

Scope. The five jobs it owns, and the fence around them: positioning and messaging, ICP and account research, channel briefs and creative, lead scoring and triage, weekly reporting and decisions. Plus the explicit out-of-scope list: it never touches spend, never publishes, never changes pricing. Write the does-not list aggressively: no posts under your name without approval, no messages to named people without approval, no numbers in external materials without a flag. Tight scope is what keeps every output shippable.

Voice. How it writes when it writes as you: tone, vocabulary, the words you never use. This is what makes 180 drafted emails usable instead of 180 things to rewrite. Pull the rules from the best three things you ever wrote, and ban the filler outright: leverage, seamless, game-changing, empower. Skip this block and by Friday the output sounds like everyone else’s newsletter.

Constraints. The grounding rules. It works only from your fact pack, cites the file behind every claim, flags anything it cannot verify, and drafts everything for your approval. Constraints are what make the output trustworthy on day 43, not just day one. They are also what turn volume into judgment: by rule, every plan it writes has to end by naming what would make it fail.

You do not write the brief alone. The operator interviews you for it:

Interview me to write my GTM operator brief. Ask one question at a time: what we sell, to whom, at what stage, with what motion, what has been tried, what our voice sounds like, and what you are never allowed to do. Push back when my answers are vague. Then write the brief in four parts, identity, scope, voice, constraints, and save it as operator-brief.md for my approval.

The full assembled version, ready to paste, is in section 7. First, the files it stands on.

3. The six-file fact pack

Every bad AI marketing output has the same root cause: the model guessed, because nobody gave it the facts. The fact pack is the fix. Six short files, written once, updated monthly, and every recommendation the operator makes cites them.

gtm/
  01-company.md    what we are: product, stage, motion, pricing, proof points
  02-icp.md        who we sell to: personas, pains, buying triggers, disqualifiers
  03-product.md    what it does: features mapped to outcomes, objections and answers, competitors
  04-channels.md   what has run: every channel tried, what it cost, what converted, what died
  05-voice.md      how we sound: tone, vocabulary, banned phrases, three real writing samples
  06-week.md       what is true right now: this quarter's targets, last week, decisions pending, open questions

The rule that makes this work: if it is not in the pack, it does not get asserted. The operator either asks you, or ships the claim flagged [CONFIRM]. No invented case studies, no imagined funnel numbers, no positioning based on vibes.

Two design choices worth naming. Your funnel numbers do not get a static file, because the operator reads them live from your connected CRM and analytics; what it cannot read anywhere is your targets and your context, so those live in 06-week.md. And 06-week is the only file that changes weekly: ten minutes every Monday morning, what happened, what is pending, what is open. Files 01 through 05 you will write once and barely touch for a month. And the operator refuses to plan from an old picture: if the week file has not been touched in seven days, it asks for the update before it works.

Build it in one sitting:

Build my GTM fact pack. Interview me file by file: 01-company, 02-icp, 03-product, 04-channels, 05-voice, 06-week. For 04-channels, pull what you can see from my connected analytics and ad accounts first and make me confirm it. For 05-voice, read three things I wrote and extract the rules. For 06-week, ask me for this quarter's targets and what is open right now. Write all six files, keep each under a page, and list every fact you could not verify with a [CONFIRM] flag.

Two hours, most of it you talking. This is the brief your future marketing hire will thank you for.

Build the pack before you ask for a single ad.

4. The five jobs it owns

Each job below is a real deliverable set with a paste-ready prompt. Run them in order the first week, then let the loops in section 5 keep them alive.

Job 01. Positioning and messaging

The positioning statement, value props per persona, tone of voice, objection handling.

Using 01-company, 02-icp, 03-product and 05-voice: write our positioning statement, then three value props per persona with the evidence behind each, the tone-of-voice card, and the top ten objections with the answer to each. Every claim cites its file. Where the pack is silent, ask me instead of inventing. Show me the full pack before anything ships anywhere.

Job 02. ICP and account research

The persona library, account briefs, outreach angles.

Using 02-icp: build the persona library, one page per persona, pains, triggers, disqualifiers, where they spend time. Then pull [20] target accounts that fit, from my CRM and my connected sources, and write an account brief for each: why now, the angle that fits their situation, and the opener I would actually send. Anything you cannot verify gets [CONFIRM], not asserted.

Job 03. Channel briefs and creative

Every campaign briefed and every ad drafted, across Meta, Google, LinkedIn, content, and email.

Using 04-channels, 01-company and 05-voice: brief the next campaign on [channel]: audience, message, offer, format, budget band, and the one metric that decides if it worked. Then draft the creative: [12] ad variants with headline, primary text and visual direction, plus the landing copy. Drafts only. Nothing launches, nothing spends, until I say yes.

Job 04. Lead scoring and triage

Every inbound scored against your ICP, the first reply drafted, the founder-led ones flagged.

Score every new inbound from [CRM / form / list] against 02-icp: A, B, or C, with the reason in one line. Draft the first reply for every A and B in our voice, and queue them for my review. Flag any account that needs founder-led attention and tell me why. Nothing sends without my yes.

Job 05. Weekly reporting and decisions

The Monday plan, the daily triage, the monthly retro.

Every Monday morning: pull last week's numbers from my analytics, ad accounts and CRM, compare them against the targets in 06-week, and give me the plan: what to keep, what to kill, what to scale, what to test. Maximum three decisions, each with the number behind it. One page. This is the meeting I hold with you instead of a marketing team.

Two adaptations that come up. If your motion is partnerships or community rather than paid, keep the five jobs and swap the channel list inside Job 03 for partner briefs and community programming. If you have no inbound volume yet, park Job 04 until you do. The default for most pre-Series-A B2B SaaS: keep all five.

Five jobs. Run job 01 first: everything else inherits its language.

5. The three operating loops

Jobs are what the operator owns. Loops are when it runs. Three of them, and together they are the operating rhythm a first marketing hire would have taken two quarters to establish.

The Monday plan. Weekly, 30 minutes of your attention. The numbers against targets, and three decisions maximum: keep, kill, scale, test. You decide, it executes the drafts.

The daily triage. Every morning, 10 minutes. New leads scored, first replies drafted and waiting, founder-led accounts flagged, and the one anomaly in yesterday’s numbers worth looking at.

The monthly retro. Once a month, the honest one. What shipped, what worked, what died, with numbers. Then the part most founders skip: it updates 04-channels.md and 06-week.md with what the month proved, and proposes next month’s thesis. This is why the operator is smarter on day 43 than day one: the fact pack learns.

One warning. If you only open the operator when a task lands on you, you will get good drafts and nothing that compounds. The rhythm is where it compounds: the first Monday plan is serviceable, the third is sharp, and by the second month it reads like it came from someone who has been inside your company for a year, because the retro and the week file keep teaching it. Book the three loops into your calendar before you build a single campaign.

Schedule all three inside Houston:

Put the three loops on a schedule: the Monday plan every Monday at 7am, the daily triage every weekday at 8am, the monthly retro on the first of the month. Every output is a draft that waits for my yes. Show me the first run of each before the schedule goes live.

Protect the 30 Monday minutes. The whole system is priced at you actually reading the plan.

6. Connect it to your stack

The operator is only as good as what it can see. Connected read-only to your stack, it stops guessing and starts reporting.

→ Your CRM: reads leads and deals for scoring and account research, drafts updates for your approval
→ Your analytics: reads traffic, conversion, and funnel numbers for the Monday plan
→ Your ad platforms: reads spend and performance across Meta, Google, LinkedIn; drafts campaigns and variants, never launches them
→ Your email: drafts replies and sequences, sends nothing

Here is the split on how much access to give it, because we argue about this one in the office.

Julian’s take: an operator connected to ad platforms and a CRM is holding real money and real relationships. A wrong budget change or a wrong bulk send does not sit in a draft, it lands. Read-only is not caution, it is engineering.

Juan’s take: the entire point is a loop that runs without you babysitting every step. If every action queues on the founder, you did not replace the bottleneck, you became a slower one.

Where we land: reads are free, writes are gated, money is human. Connect everything read-only in week one. Let it draft without limits. Keep three things permanently human: anything that spends or changes spend, anything that publishes, and any message to a named account. That is the whole gate list, and it never gets longer than that.

And connect narrowly: the pipeline, not the whole CRM; the metrics, not raw user records. A scope gets wider on the day a loop needs it, not before.

Connect the CRM and analytics first. The ad platforms can wait until the first Monday plan asks for them.

7. The paste-ready operator definition

Everything above, assembled. Paste this into Houston as your operator’s standing definition, swap the brackets, and it holds across every session:

You are the GTM Specialist for [company]. You work for me, [founder name], and I make the final call on everything. You are a senior growth operator: opinionated, direct, biased toward shipping, allergic to vague marketing language. You do not hedge. If you do not know something, say so and say how we would find out.

Scope, what you own: positioning and messaging, ICP and account research, channel briefs and creative, lead scoring and triage, weekly reporting and decisions. Five jobs, nothing else.

Scope, what you never do: you never publish, never send, never spend, never change a budget or an audience. You never post anything under my name without my approval, never contact a named person without my approval, and never commit to a number in external material without flagging it for my review. You prepare, I decide.

Ground rules:
1. Your sources of truth are the fact pack, 01-company.md, 02-icp.md, 03-product.md, 04-channels.md, 05-voice.md, 06-week.md, and what you can read from my connected tools. Cite the source behind every company-specific claim, like (source: 04-channels.md). If a fact is in neither, you do not invent it: you ask me, or you ship the claim flagged [CONFIRM]. Invented quotes, statistics, or capabilities are the one unforgivable failure.
2. Write in the voice defined in 05-voice.md. Short sentences. Specific numbers over vague claims: "38 demos booked, 9 held", never "demo attendance was low". Active voice. Banned words: leverage, seamless, game-changing, revolutionize, empower, supercharge, next-level, world-class. No em dashes anywhere. If a sentence could appear in any company's marketing, rewrite it until it could only be ours.
3. Every plan ends by naming what would make it fail and the early signal to watch for.
4. Fewer, better assets over more, mediocre ones. Pricing strategy, brand redesign, and hiring decisions are out of scope: if I ask, give me a two-line opinion and route back to the five jobs.
5. At the start of every session, read 06-week.md. If it is more than seven days old, ask me to update it before doing anything else.

The three loops:
- Monday plan, weekly. Inputs: 06-week.md and last week's numbers from my connected tools. Output: prior-week recap, top three wins, top three frictions, three proposed decisions (keep, kill, scale, or test) each with the metric that will prove it right, a task list of at most seven items, and the failure risks.
- Daily triage, every weekday. Inputs: new leads and whatever I add. Output, under 400 words: today's three priorities, what to defer, what to delegate, what to ignore, and one observation worth remembering. Score new inbound against 02-icp.md as A, B, or C with a one-line reason, draft first replies for A and B, and flag founder-led accounts.
- Monthly retro, first of the month. Inputs: the month's Monday plans and shipped work. Output: the patterns the weekly loops missed, proposed edits to this brief and the fact pack, at most five priorities for next month, and the single biggest open question. Then draft the updates to 04-channels.md and 06-week.md with what the month proved, for my approval.

How we work together: keep outputs short and structured. If a question does not change what you will produce, do not ask it, and never ask more than three in one turn. Creative work arrives as a spread of three to eight options, one line each on why it might win, and I choose. If I reject something, find out with one question whether I am rejecting the idea or how it was presented, then rework it.

The quality bar: if I would need to rewrite it before a customer or my own feed could see it, it is not done. Do not ship it. Say what is missing and ask me for it.

First run: check the fact pack exists. If any file is missing or stale, interview me to fix it before any other work. The brief comes before the work, always.

That block is the whole hire. Save it once, and every conversation starts with an operator that already knows the company.

8. The seven-day rollout

The schedule, paced so the brief exists before the output does.

→ Day 1: install Houston with the code getsh*tdone, paste the operator definition, and let the first run interview you for the brief
→ Day 2: finish the six-file fact pack and approve every file, this is the two hours that replace two quarters of ramp. Then smoke-test it: “describe my company back to me in five sentences, using only the fact pack”, and fix whichever file it gets wrong
→ Day 3: run Job 01 and approve your positioning pack, everything downstream inherits its language
→ Day 4: connect your CRM and analytics read-only, then run Job 04 over your last 100 inbound leads and read what you have been sitting on
→ Day 5: run Job 03, brief one channel, and hand the drafted variants to whoever ships your ads
→ Day 6: run Job 02 and get 20 account briefs with openers queued for your review
→ Day 7: schedule the three loops and take your first Monday plan on Monday

Set expectations honestly: in week one you will edit most of what it drafts, and that is normal. By week three you are approving more than you touch, and the Monday plan is the one meeting you would not cancel. Setup week costs you a few focused hours, most of them the fact pack. After that, the system runs on loop minutes.

Then run it for 30 days before you reopen the hiring doc. You will either discover you did not need the hire yet, or you will know exactly which hire you need, with the brief already written for their first day.

The bottom line

The first marketing hire is not the unlock, the brief is. Positioning, ICP, channel state, voice: that work is yours, and hiring someone to excavate it out of you at USD 60,000 a year is the most expensive way to write six short files.

The GTM Specialist forces the brief on day one and runs the five jobs from it the same afternoon: positioning, research, channel briefs, lead triage, and the Monday plan, for USD 20 to 200 a month on the model subscription you already pay for. Grounded in your fact pack, gated on your yes, compounding every month the retro updates the files.

Sofia ran the loop for 43 days and bought a part-time producer instead of a USD 60,000 hire. Your answer might be different. But make it a decision you ran, not one you read on a job board.

Write the brief today. Run the loop for 30 days. Then decide.

Want us to stand up your GTM Specialist with you?

You can do this yourself: install Houston, paste the operator definition, build the fact pack, and run the seven days. For most founders that is exactly the right move, and it is the whole point of this post.

If you would rather have it running cleanly the first time, we will do it with you. We install Houston on the right path, write the operator brief and fact pack with you in one working session, connect your CRM, analytics, and ad accounts read-only, load the five jobs, and schedule the three loops, so you walk out with an operator mid-loop, not a to-do list. We take on a small number of founders who want it running in days.

Just a quick note before you go! This is what your premium subscription gets you, every month:

Early founders are already inside. You are in good company.

We are building Houston, the desktop app that lets anyone build, connect, and run AI agents across the tools they already use, with no code. The GTM Specialist in this post is one operator you run on it.

Houston is the harness that runs it, and the rest of the team after it: the outbound agent, the fundraising agent, the ops agents, all on the same brain, with your judgment over all of them.

1,500 builders across 46 countries are already inside, and 45% come back every week. Houston is invite-only until we open to the public.

Get it at gethouston.ai.

The code to get in is getsh*tdone.

Hope this was valuable.

Cheers,
Juan

Houston. AI agents that actually do the work.
Mission Control.

Building with AI, from Silicon Valley.

150 Family Offices

Mission Control — Mon, 27 Jul 2026 07:35:39 GMT

Hey everybody, welcome back to Mission Control.

This post starts something new. From today, every month, paid subscribers get a named, verified investor list dropped into their inbox as a ready-to-import spreadsheet. No forms to fill, no access to request. You open the post, you download the file, you start sending.

Drop number one is the category fund managers ask about more than any other: family offices.

If you are raising Fund I, II, or III, running a real estate vehicle, or raising LP capital of any kind, family offices are the check almost everyone underestimates. They decide in weeks, not quarters. They write checks that matter. They skip the committee theater that makes institutional money slow. And their direct contacts are the hardest in the entire LP universe to find, which is exactly why most GPs never message them.

Inside this post: a spreadsheet of 150 family office decision makers who actively allocate to outside funds. Real names, verified work emails, live LinkedIn URLs, office, location, and AUM where disclosed. Import it into your outreach stack tonight.

And more important than the file: the recipe. This list came out of four prompts run against 8Raise, the investor search engine that lives natively inside Houston, in one sitting. We are handing you those four prompts, because the file is this month’s gift and the recipe is permanent. Next time you need institutional LPs in Europe, or family offices with real estate sleeves in the Gulf, you will build the list yourself in minutes.

Here is the honest fork before we open the file, because list drops have a deserved reputation problem.

Felipe’s take: speed wins raises. A verified list in your hands tonight beats a perfect process next month. Import the file, pick your thirty, and let the first allocator replies teach you what your pitch is missing.

Julian’s take: every list is a snapshot that starts aging the day it is exported. People rotate firms, mandates close, emails die. If you only take the file, you own a depreciating asset. If you take the recipe, you own the machine that prints fresh ones.

Where we land: send from the drop this week, own the recipe forever. The file gets you moving tonight, the four prompts keep the list alive every month after, and the re-run habit in section 4 is what separates a pipeline from a pile of rows.

By the end of this post you will have:

→ The 150-row family office spreadsheet, verified and ready to import
→ The reason family offices are the most underrated LP check in your raise
→ The four prompts that built the list, paste-ready, to rebuild it for any category
→ The one-week playbook: import, pick your thirty, message, book the calls
→ The 12-month drop calendar, so you know which list lands next

Here is what is inside.

Table of contents

Why family offices are the most underrated LP check
The 150: what is inside the file
The four prompts that built it
Use it this week: import, message, book
The monthly drop calendar
The prompt templates for the next drops

Inside you get:

→ The 150 family office spreadsheet in this post, plus a new investor list every month
→ Paste-ready agent builds and prompt packs across fundraising, outbound, and GTM
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

💭 As a premium subscriber you also get every other playbook in this series. Recent ones readers open:

1️⃣ The AI Agent That Runs Your Entire Raise
2️⃣ The VC’s Agent Stack
3️⃣ How We Run Our Entire Outbound on One AI Agent

🗣 Or you can always invite a friend and earn rewards along the way:

→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium

Early founders and fund managers are already inside.

🤖 Shortcut: paste this whole article into Houston and say “set up my LP list.”

→ It will ask what you are raising: fund size, strategy, minimum commit, geography
→ It will rewrite the four prompts in section 3 for your exact raise
→ It will run them against 8Raise and hand you your own list, not just ours
→ It will queue the first-touch drafts for your review, nothing sends without you

This post is written to be opened, not just read.

Run this on Houston

The prompts in this playbook run inside Houston, where 8Raise lives as a native connector, on your own model subscription and your own machine.

→ Get the app at gethouston.ai
→ The code to get in is getsh*tdone

🚀 Let’s begin!

The tools we use in this article

→ Houston, where the prompts run
→ 8Raise, the investor search engine, native inside Houston
→ Claude Code or Codex, on the subscription you already pay for
→ HeyReach, Instantly, or your CRM, as the import targets for the file

One thing before the list: everything below assumes you can run the prompts somewhere. That somewhere is Houston. Register at gethouston.ai with the code getsh*tdone, connect 8Raise from the catalog, and section 3 stops being reading and starts being your own list.

1. Why family offices are the most underrated LP check

Watch where fund managers spend their outreach hours and you will find the same pattern everywhere: everyone chases the institutions. The data room is built for them, the DDQ is written for them, the placement agent’s book is full of them. Meanwhile the family office side of the LP universe, which in private markets is a pool at least as deep, gets almost no systematic outreach at all.

That imbalance is your opening, for three reasons.

They decide in weeks, not quarters. An endowment investment committee meets on a calendar. A consultant-led process runs most of a year before anyone says yes. A family office principal can read your deck this week, take the reference calls next week, and move to docs the week after, because the person reading the deck is the person who approves the commit.

The checks are real. The offices in this file manage from $50M to $80B, with a median of $641M. These are not angel checks with extra steps. For an emerging manager raising $25M to $300M with $1M to $5M minimums, a handful of family office commits is a first close.

Nobody else is in their inbox. Every GP raising right now is messaging the same few hundred institutional contacts from the same public lists. Almost none of them run systematic family office outreach, because the contacts are genuinely hard to find: no fund database coverage, no published commitments, often one LinkedIn profile and an email format nobody can guess. Scarce inboxes read carefully.

The catch is that last point cuts both ways: the hardest contacts to find are the most valuable to have. That is the problem 8Raise’s LP mode exists to solve, and it is why this file is worth more than its row count.

Stop competing for the crowded inboxes first.

2. The 150: what is inside the file

Before you scroll to the download, here is exactly what you are getting, so you can judge it like the operator you are.

→ 150 decision makers, not gatekeepers: founders, principals, CIOs, partners, heads of investments, investment directors. The people who approve the commit
→ $393.5B in combined disclosed AUM across the 88 firms that publish numbers. The other 62 keep their size private, and quiet capital is often the largest
→ Median AUM $641M, range $50M to $80B: sized for emerging managers raising $25M to $300M with $1M to $5M minimums
→ Every office allocates to outside funds. No direct-only shops, no public-markets-only books. Every row is a live LP candidate

Geography, so you can plan your time zones:

→ United States: 30 offices
→ Switzerland: 15 offices
→ United Kingdom: 12 offices
→ Germany: 12 offices
→ Canada: 11 offices
→ Cyprus, Czechia, Romania, and UAE: 18 offices combined
→ Plus 52 offices across 25 other countries

Every row carries the full working set: name, title, firm, verified work email, live LinkedIn URL, city and country, and AUM where disclosed. Every email went through the 8Raise verification waterfall, Apollo, then Prospeo, then Dropcontact, then ZeroBounce, with a bounce target under 4 percent. Every LinkedIn URL was live as of last week, so firm rotations are caught, not fossilized.

The download:

The Family Office List

Ready to import into HeyReach, Instantly, your CRM, or straight into Houston. And once it is in Houston, rank it against your own raise with one paste:

Read the family office spreadsheet I just uploaded. Group the offices into AUM bands: 50M to 500M, 500M to 2B, and 2B plus. For each band, rank the ten best fits for a [your strategy] fund raising [your size] with [your minimum] minimums, and tell me why each one fits in one line. Output the top 30 as a table I can push into my outreach tool. Do not invent a single row.

Sixty seconds later you have your thirty, not just our one hundred fifty.

Judge every list you ever buy by this standard.

3. The four prompts that built it

This is the section that outlives the file.

The list above came out of one conversation inside Houston with 8Raise connected: four prompts, run in order, from first search to exported spreadsheet. Here they are, paste-ready. Swap the brackets and the same recipe builds any investor list you will ever need.

Prompt 1 — Discover. Cast the net, in LP mode, with the filters that matter:

Search 8Raise in LP mode for family office decision makers, worldwide.

Keep only:
- People who hold the decision seat: founder, principal, partner, CIO, head of investments, investment director, or investment committee members
- Single family offices and multi family offices
- AUM between 100M and 50B
- Offices that allocate to outside funds across venture, private equity, private credit, real estate, or hedge funds. Exclude direct-only offices
- At least one outside fund commitment inside the last 36 months

Bring back up to 200 people, largest AUM first.

Prompt 2 — Filter. Cut everything you would regret sending to:

Now clean the 200. Remove anyone who is:
- Operational only (CFO, COO, office manager, EA, IT) unless they also sit on the investment committee
- Missing a verified email or a LinkedIn URL
- At an office with no outside fund commitment in the last 24 months
- At an office that states it runs internal capital only

Tell me how many survive and show the ten largest by AUM so I can sanity-check the cut.

Prompt 3 — Enrich. Turn names into sendable rows:

Enrich every surviving row: full name, title, firm, city, country, region, AUM in USD millions where disclosed, and the office's allocation mix across venture, PE, real estate, credit, and hedge. Add the most recent known fund commitment and its date where public.

Run every email through the verification waterfall: Apollo, Prospeo, Dropcontact, ZeroBounce. Refresh every LinkedIn URL to catch firm moves. Drop any row whose email does not verify. A dead row is worse than no row.

Prompt 4 — Export. Make it repeatable, then ship it:

Save this search under "Family Offices, LP mode" so it can re-run monthly. Export the final list as a spreadsheet with the columns in this order: name, title, family office, email, LinkedIn, location, AUM. Confirm the final row count before you finish.

That is the whole build. Four pastes, one sitting, a verified file at the end. The reference points that shaped this one: role filters decide whether you reach the decision or the gatekeeper, the 36-month commitment filter is what separates allocators from holding companies, and the verification step is not optional, because a bounced email to a family office is not a missed shot, it is a burned door.

And if you only have time for one paste, compress the whole sequence:

Search 8Raise in LP mode and build me a verified list of family office decision makers worldwide who allocate to outside funds: decision-seat roles only, AUM 100M to 50B, at least one outside commitment in 36 months, emails through the full verification waterfall, LinkedIn URLs refreshed. Save the search for monthly re-runs and export the spreadsheet with a confirmed row count.

Slower per run, identical result. Run the recipe, not the memory of it.

4. Use it this week: import, message, book

A list is inventory. Here is the week that turns it into calls, in six steps.

Step 1, import. Drop the file into your outreach stack: HeyReach for the LinkedIn side, Instantly for email, or your CRM if that is home base. The format imports clean, no surgery needed. Or upload it into Houston and let the agent hold it.

Step 2, pick your thirty. One hundred fifty is the universe, thirty is a send. Use the ranking prompt from section 2: your strategy, your size, your minimums, plus time zone overlap, because allocators book faster with people awake in their working day.

Step 3, write the one message that works on this audience. Family offices receive far less fund outreach than institutions, which means a generic raise announcement stands out for the wrong reason. What earns replies is specificity: name something true about their allocation history and connect your fund to it in one line. The shape we use:

Subject: [fund they backed] and [your fund name]

Hi [first name],

[Family office] backing [fund or GP they committed to] caught my attention, because we run a [one-line thesis] strategy in the same lane, and our first close is done at [size or anchor].

Worth 20 minutes to see if the pattern fits?

[Your name]

Three sentences. The deck and the data room come after the call, not before.

Step 4, send Tuesday morning, their time. Early week, early day, local time zone. Skip Monday inbox triage and the Friday fade. One follow-up on Thursday, then stop: family office allocators who recognize the pattern will surface on their own clock, and over-pursuit reads exactly how it sounds.

Step 5, track every reply. Every response, yes or no, goes into your CRM or your tracking base the day it lands. The nos teach you the pitch; the silence teaches you the targeting.

Step 6, re-run the search in 30 days. Offices open to outside funds every month, and Prompt 4 saved your search precisely so the re-run is one click. Or skip it, because the next drop does it for you, which is section 5.

Here is the split on how far to automate this, because we ran the argument ourselves.

Felipe’s take: the whole point of an agent is the loop running without you. Let it import, rank, draft, send, follow up, and log, and spend your saved hours on the calls.

Julian’s take: a message to a named allocator is an irreversible write to a tiny, high-trust market that talks to itself. One templated blast to the wrong fifty people costs more than the agent ever saves. Sends stay human.

Where we land: the agent builds, refreshes, ranks, and drafts; you read and you send. Same gate we hold everywhere: drafts by default, named-person sends by hand. The leverage is in never building the list manually again, not in removing your judgment from the send button.

Thirty sends, one Tuesday, gates on. That is the week.

5. The monthly drop calendar

This post is drop one of a standing series. Every month, a fresh list: different category, same 150-row depth, same verification standard, same import-ready format, landing the first Tuesday of the month.

Different months serve different raises. Skip the ones that are not yours; the rotation comes back around.

→ Drop 01, this post: 150 family offices, LP mode. For VCs, PE GPs, RE sponsors, any fund manager raising LP capital
→ Drop 02: 150 institutional LPs: endowments, foundations, fund of funds, sovereign wealth, insurance, pensions. For funds raising anchor commitments
→ Drop 03: 150 active sector VCs, first sector AI infrastructure, applications, and dev tools. For founders raising venture
→ Drop 04: 150 real estate allocators: RE fund of funds, family offices with RE sleeves, opportunistic LPs. For sponsors and RE fund managers
→ Drop 05: family offices refreshed: the same four prompts re-run, surfacing everyone who opened to outside funds since drop one
→ Drop 06: institutional LPs refreshed
→ Drop 07: sector VCs, next sector: climate, energy, deep tech
→ Drop 08: real estate refreshed
→ Drops 09 to 12: the rotation repeats with new sectors, new geographies, new AUM bands

All of it is included in the premium subscription. No extra tier, no separate purchase, no form between you and the file.

Put the first Tuesday in your calendar now.

6. The prompt templates for the next drops

One more layer, because the recipe generalizes further than family offices.

Each future drop ships with its own four-prompt recipe inline, so by the end of the rotation you hold a folder of recipes covering every major investor category: run them whenever your raise shifts, hand them to whoever runs Fund II. Here are the discover prompts for the next three, today. The filter, enrich, and export prompts barely change; discovery is where the category lives.

Drop 02 — Institutional LPs:

Search 8Raise in LP mode for institutional allocators, worldwide. Keep only: decision roles (partner, director of investments, head of private markets, head of alternatives, portfolio manager); firm types endowment, foundation, fund of funds, sovereign wealth, insurance asset manager, pension; AUM 500M to 200B; at least three venture or PE fund commitments in the last 36 months. Bring back 200, largest first.

Drop 03 — Sector VCs (AI):

Search 8Raise for active venture partners. Keep only: partner, general partner, managing director, principal at VC firms; sector exposure across AI infrastructure, AI applications, dev tools, and ML ops; led or co-led at least two sector deals in the last 18 months; stages seed through Series B. Bring back 200, most recently active first.

Drop 04 — Real estate allocators:

Search 8Raise in LP mode for real estate capital. Keep only: decision roles (partner, director of investments, head of real estate, portfolio manager); firm types RE fund of funds, family office with an RE sleeve, RIA with private RE allocation, endowment or foundation with an RE bucket; strategies opportunistic, value-add, core-plus; at least one outside RE fund commitment of 25M or more in the last 18 months. Geography yours to set. Bring back 200.

And the dials you can turn on any of them without breaking the recipe: geography (swap worldwide for Europe, the US, the Gulf, or one city), asset class (add a commitment filter for the class you raise in), AUM band (tighten to the band that anchors funds your size), structure (single family offices commit bigger and faster, multi family offices review more managers per year), and first-time openness (require at least one first-time fund commitment in 36 months, the filter that matters most for Fund I).

Save every variation as its own search. Re-runs are free of effort forever after.

The bottom line

Family offices are the LP check with the best ratio of decision speed to check size to inbox competition, and the reason nobody messages them is the reason you should: the contacts are hard to find. This post handed you 150 of them, verified, with the exact four-prompt recipe that built the file inside Houston with 8Raise connected.

Import the file tonight. Pick your thirty with the ranking prompt. Send three-sentence messages that name a fund they actually backed, Tuesday morning their time, follow up once, log everything. Re-run the search in 30 days, or let next month’s drop do it for you, because from here there is a fresh list every first Tuesday.

The file is this month’s gift. The recipe is yours forever.

Want us to stand up your LP-prospecting agent with you?

You can do this yourself: register, connect 8Raise, run the four prompts, and work the week in section 4. For most fund managers that is exactly the right move, and it is the whole point of this post.

If you would rather have it running cleanly the first time, we will do it with you. We install Houston on the right path, connect 8Raise and your outreach stack, tune the four prompts to your exact strategy, size, and minimums, load the ranking and drafting prompts with the gates set the way section 4 says, and schedule the monthly re-run, so you walk out with a live LP pipeline instead of a spreadsheet in a downloads folder. We take on a small number of fund managers who want it running in days.

Just a quick note before you go! This is what your premium subscription gets you, every month:

→ A new named, verified investor list every month, starting with this one
→ Paste-ready agent builds and prompt packs across fundraising, outbound, and GTM
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

Early founders and fund managers are already inside. You are in good company.

We are building Houston, the desktop app that lets anyone build, connect, and run AI agents across the tools they already use, with no code. The list in this post came out of one Houston conversation with 8Raise connected, and that is the real story: the search engine, the enrichment, the verification, and the export ran as one loop, on our own model subscription, with every send gated on a human. Load the same loop for your raise, and the rest of your fundraising, the outreach, the follow-ups, the investor updates, runs on the same brain, with your judgment over all of it. 1,500 builders across 46 countries are already inside, and 45% come back every week. Houston is invite-only until we open to the public. Get it at gethouston.ai. The code to get in is getsh*tdone.

Hope this was valuable.

Cheers,
Felipe

Houston. AI agents that actually do the work.
Mission Control. Building with AI, from Silicon Valley.

How We Built a CMO Instead of Hiring One

Mission Control — Sun, 26 Jul 2026 09:32:02 GMT

Hey everybody, welcome back to Mission Control.

Two of us run Houston. Our growth moves like a team of ten.

For most of last year I assumed the fix for that was a hire. A real marketing leader, someone with taste and a track record, who would walk in and make the whole function make sense. I wrote the job description four times. I never posted it.

Here is the slow way, and I watched three founders I respect do exactly this. You post the role. You interview for two months. You hire someone good. They walk in, ask the obvious questions, get fragments of answers, and spend their first quarter assembling the brief that should have existed before the job description was posted. Ninety days of ramp. Fourteen months of average tenure. Then you do it again.

Here is what stopped me, and it is uncomfortable.

I could not brief the person I wanted to hire.

Not because I did not know my business. Because nowhere, in any document, had I written down how this company actually goes to market. Who we sell to. What we sell. Why anyone cares. Which channels work and which ones we run out of habit. What tone we use. What success looks like in 90 days.

Here is the honest fork, before we build anything.

If you have real volume and a written brief already, hire the human. A great marketer with a clear brief will out-run any agent stack, and it is not close.

If you have neither, the hire is not the unlock. It is the bottleneck, because you are asking a person to build the asset while executing against it.

The brief is the asset. The hire is only the executor.

Building a CMO agent forces you to write the brief, because the agent cannot start without it. That is not a clever side effect. That is the entire value.

By the end of this post you will have:

→ The five jobs a CMO owns, and why you should never let one agent own more than five
→ The operator brief: identity, scope, voice, constraints, and the “does not do” list that protects you
→ Our five-agent growth team, the one that actually runs the motion
→ Our nine-agent content engine, and the ninth agent that makes it compound
→ The three loops: Monday plan, daily triage, monthly retro
→ The four decisions we never hand to a model

Here is what is inside.

Table of contents

Why the first marketing hire is the bottleneck
The five jobs your CMO agent must own
The operator brief
The growth team: five agents
The content engine: nine agents
The three loops
The four human gates

Before we get into it, a quick heads up: the Mission Control subscription price goes up once we pass 100 paid subscribers. If you have been thinking about premium, now is the moment. Current subscribers lock in today’s rate forever. No tricks, just a real counter.

The reason is simple. We are building the publication into the place where every Houston system gets written down, and the builds, the agent specs, and the guides are all part of that.

Subscribe now. Pay less, forever.

USD 20/month or USD 150/year today. After we cross 100 paid subscribers, monthly goes to USD 30 (+50%) and annual goes to USD 195 (+30%).

Inside you get:

→ Every agent build we ship, paste-ready, across marketing, growth, and engineering → The operator briefs and skill files behind each one
→ The Houston agent stack, refreshed as it changes
→ Every future playbook in this series

No contracts. Cancel anytime. Rate locked for life.

🗣 Or invite a friend and unlock rewards along the way:

→ 3 friends = 1 month of premium
→ 5 friends = 3 months
→ 25 friends = 6 months

Early founder-marketers are already inside.

Shortcut: install Houston at gethouston.ai with invite code getsh*tdone, open a fresh agent, paste this whole post, and say “build my CMO agent, start with the operator brief.”

→ It will ask for your ICP, your channels, your voice, and your current numbers
→ It will write the brief block by block, including the “does not do” list
→ It will scaffold the five growth agents and the content engine
→ You finish the week with one loop actually running

This post is written to be built, not just read.

Why Your AI Agent Gets Dumber With Every Tool You Add

Mission Control — Thu, 23 Jul 2026 13:18:34 GMT

Hey everybody, welcome back to Mission Control.

Every tool you connect to your agent lands in its context. And every tool in its context is a tax the model pays on every single turn, whether it uses that tool or not.

Connect fifty tools and the model now reads a fifty-item menu before it does anything else. It gets slower. It gets more confused about which tool is for which job. It starts reaching for the wrong one on tasks it used to get right. And the worst part is that this happens gradually, so you blame the model, or the prompt, or the phase of the moon, when the real cause is the pile of tools you kept adding because adding tools felt like making the agent more capable.

I know the failure mode because we shipped it. Early on we bundled everything we could into the agent. More capability, we thought. Then we watched a perfectly good model pick the wrong tool for a simple task, over and over, because we had buried the one right tool under forty it did not need. The model was fine. We had drowned it.

Here is the honest fork. You can keep bolting tools onto your agent and keep paying that tax on every turn, or you can strip the surface down to almost nothing and connect a thousand apps behind it without the model ever seeing the pile. We rebuilt Houston around the second road. This post is exactly how it works, with the real mechanics, and a prompt you can run on your own setup today to see what your tools are costing you.

By the end of this post you will have:

→ A clear picture of what a single tool actually costs your agent, in tokens and in mistakes
→ The pattern that puts a thousand apps behind two tools, shown end to end
→ The permission rule that keeps the tool count low without opening a security hole, with the exact cases it catches
→ A prompt that audits your own agent and tells you what to cut, plus what to do with the output

Here is what is inside.

Why every tool is a tax on every turn
A thousand apps behind two tools
Stripping the built-ins the agent does not need
The permission rule that keeps it safe
Auditing your own setup

Before we go further

Mission Control is a paid publication, and the rate you lock in today is the rate you keep.

Right now it is USD 20 per month, or USD 150 per year. Once we pass 100 paid subscribers it moves to USD 30 per month and USD 195 per year. Subscribe before then and you keep today’s rate for life.

What you get:

→ Every Mission Control playbook, the moment it ships
→ The paste-ready shortcuts and skill files inside each one
→ The full archive, searchable
→ First access to every new agent we build

Subscribe now. Pay less, forever.

No contracts. Cancel anytime. Rate locked for life.

Remember

The other playbooks in this series:

The AI Agent That Runs Your Entire Raise
Why Your AI Agent Gets Dumber With Every Tool You Add (you are here)
The AI CMO Guide: build your marketing team

Share Mission Control

Refer a few friends and your own subscription is on us.

3 friends = 1 month free
5 friends = 3 months free
25 friends = 6 months free

Shortcut

Before the walkthrough, here is the audit. Paste this into Claude Code and it will tell you what your tools are costing you.

Audit my tool surface.

1. List every tool currently available to you, with its name.
2. For each tool, estimate the size of its schema in tokens.
3. Total it, and tell me what fraction of a fresh context window my tools
   consume before I have said anything.
4. Flag any tool that overlaps with another, or that a general-purpose tool
   could replace.

Give it back as a table sorted by token cost, largest first, with a one-line
recommendation per tool: keep, merge, or drop.

Run it once, on your most-connected setup. You will find something to cut. Section five walks through exactly what to do with the output.

The Investor Search Guide: how to find VCs, angels, family offices, and funds of funds with AI

Mission Control — Tue, 21 Jul 2026 14:31:05 GMT

Hey everybody, welcome back to Mission Control.

There are four kinds of people who can put money into your company, and most founders treat them as one.

Angels, venture funds, family offices, and funds of funds are not four flavours of the same thing. They hold different money, they answer to different people, they decide in different ways, and you find each one through a completely different door. Blast the same message at all four and you will get the reply rate of someone who understood none of them, which is to say almost nothing.

When I raised for the first time, I did not know this. I had a single list called “investors,” sorted by how famous the fund was, and I sent all of them the same email. The angels thought it was too corporate. The funds thought it was too thin. The family offices never saw it, because you do not reach a family office through a cold email, and I did not know that yet. The round that eventually closed came from people I found much later, once I understood that finding an angel and finding a fund are two different jobs.

Here is the honest fork. You can keep treating “investors” as one big list and keep getting the blended non-response of four audiences you did not tailor to, or you can learn what the four types actually are and find each one the way it is actually found. This post is the second road. It is not a list of tools. It is

the map of who funds what, and the exact method to find each type with AI.

By the end of this post you will have:

→ The four kinds of capital, clearly, and who funds what stage
→ How to find venture funds with AI, down to the partner who will actually reply
→ How to find angels with AI, when angels are in no directory anywhere
→ How to find family offices with AI, when you cannot cold-contact them at all
→ How to place funds of funds, and why you are researching them, not pitching them → A data room that is ready the moment any of them says yes

Here is what is inside.

The four kinds of capital
How to find venture funds
How to find angels
How to find family offices
How to place funds of funds
Sorting what you found
What to have ready when they say yes

Before we go further

Mission Control is a paid publication, and the rate you lock in today is the rate you keep.

Right now it is USD 20 per month, or USD 150 per year. Once we pass 100 paid subscribers it moves to USD 30 per month and USD 195 per year. Subscribe before then and you keep today’s rate for life.

What you get:

→ Every Mission Control playbook, the moment it ships
→ The paste-ready shortcuts and prompts inside each one
→ The full archive, searchable
→ First access to every new agent we build

Subscribe now. Pay less, forever.

No contracts. Cancel anytime. Rate locked for life.

💭 Remember

The other playbooks in this series:

From 0 to Technical Founder
The AI Agent That Runs Your Entire Raise
The Investor Search Guide (you are here)

🗣 Share Mission Control

Refer a few friends and your own subscription is on us.

3 friends = 1 month free
5 friends = 3 months free
25 friends = 6 months free

Shortcut

Before the full walkthrough, here is the single most useful move in fundraising. Paste this into Houston to find angels the way angels are actually found, through a company that already raised for something like what you are building.

You are my investor research assistant.

Take this company: [A STARTUP LIKE MINE THAT RAISED A PRE-SEED OR SEED
RECENTLY].

1. Find the individual people who angel-invested in its earliest round.
   Individuals, not funds.
2. For each, note who they are, what they did before, and what else they
   have backed in my space.
3. Flag anyone who has angel-invested in two or more companies like mine.

Give it back as a table, most relevant first.

That is one company and one type of investor. The rest of this guide does the same for all four.

Your Go-to-Market Is Running on 12 Disconnected Tools

Mission Control — Thu, 16 Jul 2026 13:51:11 GMT

Hey everybody, welcome back to Mission Control.

Here is what most go-to-market actually looks like under the hood. A tool to find accounts. A different tool to enrich them. A sequencer for email. A separate one for LinkedIn. A CRM nobody updates. A scheduler for content. A design tool. A dashboard. A spreadsheet the dashboard feeds into. By the time you count them, it is a dozen tools, twelve logins, twelve places for your data to get stuck.

And none of them talk to each other. So someone on your team becomes the human glue, copy-pasting a list out of one tool, into another, into the CRM, into the email, all day. That is not a go-to-market engine. That is a person doing data entry between twelve subscriptions.

There is a better setup, and it is not “rip everything out and buy one tool.” It is one agent that works across the stack you already have, so the copy-paste in the middle disappears. You keep the tools that earn their place. You stop being the glue.

This is not a someday capability. The pieces shipped this year, and the rest of this post is how to connect it and run it well.

Here is the honest fork before we build, because how far you consolidate is a real question.

Felipe’s take: collapse the stack. Twelve tools is twelve bills and twelve places for data to die. The fewer places your go-to-market lives, the faster you move, and most of those tools were bought to solve a problem you can now solve in one place.

Julian’s take: do not rip out a tool that is genuinely the best at its job just to have fewer of them. The problem was never the tools. The problem is that they do not talk, so a human carries data between them. You do not need fewer tools. You need one agent that works across all of them.

Where we land: keep the tools that earn their place, connect them to one agent, and let the agent do the copy-paste work between them. One brain over your stack, not one tool instead of it. You keep the strategy and the judgment. The agent runs the glue.

By the end of this post you will have:
→ A map of your GTM stack: the tools you run, grouped by the job they do
→ One agent connected across that stack, no code
→ The cross-tool prompts that replace the manual copy-paste
→ A weekly view that pulls pipeline and campaign numbers into one place
→ The gates that keep a connected stack safe

Here is what is inside.

Table of contents

What “one connected go-to-market” actually means
Map your stack: 12 tools, 6 jobs
Connect it: one agent across the whole stack
The prompts that run the glue
Tools that extend it
Automate it from Claude Code
Where the human stays in the loop
Your first week

👀 Before we get into it, a quick heads up: prices increase once we pass 100 paid subscribers. If you have been thinking about upgrading to premium, now is the moment. Subscribe today and lock in your rate for life. Once we pass 100, Monthly goes from USD 20 to USD 30 and Annual from USD 150 to USD 195. No tricks, just a real counter. The reason? We are building the tools and playbooks that let anyone build and run AI agents, and the value keeps climbing. You are going to love what is coming next 🔥

USD 20/month or USD 150/year today. No contracts, cancel anytime, rate locked for life.

Inside you get:
→ Paste-ready agent builds and prompt packs across GTM, outbound, and fundraising
→ The latest tools and updates for building with AI, no code required
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

💭 As a premium subscriber you also get every other playbook in this series. Recent ones readers open:

1️⃣ The Fundraising Agent: the AI agent that runs your raise
2️⃣ 40 Prompts That Run Your Entire Outbound
3️⃣ More builds shipping every week

🗣 Or you can always invite a friend and earn rewards along the way:
→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium

Early founders are already inside.

🤖 Shortcut: paste this whole article into Houston and say “map my GTM stack and build the agent that runs across it.”
→ It will list the tools you use and the job each one does
→ It will connect them to one agent
→ It will set up the cross-tool prompts that replace the copy-paste
→ You finish with one agent running across your whole stack

This post is written to be opened, not just read.

40 Prompts That Run Your Entire Outbound

Mission Control — Tue, 14 Jul 2026 16:30:21 GMT

Hey everybody, welcome back to Mission Control.

Most founders already do outbound the slow way. You either hire an SDR and wait three months for them to ramp, or you do it yourself, at midnight, between building the product and everything else. You find a few accounts, write a few messages, forget to follow up, and tell yourself you will get to it next week. Outbound becomes the thing that always slips.

There is a better setup. You do not need a rep and you do not need to become one. You need one agent and the right prompts. We packaged our entire outbound motion into 40 copy-paste prompts you run inside Houston: find the accounts, research them, write the sequences, chase the warm replies, and book the calls. The month of work an SDR does becomes an afternoon of running prompts and approving what goes out.

This is not a someday capability. The prompts are below, grouped by the six jobs a real SDR does, and the rest of this post is how to run them well.

Here is the honest fork before we start, because how much you let this run on its own is a real question.

Felipe’s take: let the agent run the whole top of the funnel. Sourcing, research, and drafting are volume work, and a founder has zero hours for volume work. Point the agent at all of it and get your evenings back.

Julian’s take: outbound at scale can go wrong fast. A bad, generic message does not just get ignored, it burns the prospect and, blasted wide, it burns your domain reputation too. The agent can draft forty messages in a minute and still misjudge the one that matters.

Where we land: the agent sources, researches, and drafts everything, and a human approves every send. Start small, keep it personal, and never let a message reach a named, high-value account without your eyes on it first. Automate the work, keep the send human.

By the end of this post you will have:
→ One outbound agent built in Houston, no code
→ All 40 prompts, grouped by the six jobs an SDR does
→ A sourcing and research routine that fills your pipeline daily
→ Personalized sequences and follow-ups drafted for your approval
→ The gates that keep outbound at scale safe

Here is what is inside.

Table of contents

What the outbound agent actually is
Build it: one agent in Houston
The six jobs it runs
The prompts: the full 40, grouped by job
Tools that extend it
Automate it from Claude Code
Where the human stays in the loop
Your first week

USD 20/month or USD 150/year today. No contracts, cancel anytime, rate locked for life.

Inside you get:
→ Paste-ready agent builds and prompt packs across outbound, fundraising, and GTM
→ The latest tools and updates for building with AI, no code required
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

💭 As a premium subscriber you also get every other playbook in this series. Recent ones readers open:
1️⃣ The Fundraising Agent: the AI agent that runs your raise
2️⃣ The 25 MCP servers every AI engineer should actually use
3️⃣ 40 Prompts That Run Your Entire Outbound (you are here)

🗣 Or you can always invite a friend and earn rewards along the way:
→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium

Early founders are already inside.

🤖 Shortcut: paste this whole article into Houston and say “build me the outbound agent, start with the ICP prompts.”
→ It will help you write your ICP
→ It will build your list and research the accounts
→ It will draft your sequences and set up your follow-ups
→ You finish with a working outbound agent running your pipeline

This post is written to be opened, not just read.

The Agent Skills Library

Mission Control — Tue, 14 Jul 2026 15:45:07 GMT

Hey everybody, welcome back to Mission Control.

A base model can talk. An agent that ships can be trusted to act.

The slow way to close that gap is the way I closed it, which is one production incident at a time.

You write a prompt. It works in the demo. It breaks on a Tuesday, because a tool call timed out and nothing told the model what to do next. So you make the prompt longer. Then it breaks differently, because it answered from memory instead of going to look something up. So you make the prompt longer again. Then it does something you never sanctioned, confidently, at 3am, and you add a paragraph about that too.

Eighteen months later you have a four-thousand-word prompt that nobody on the team will touch, that fails in ways nobody can localize, and that you would not put near production.

The gap was never the prompt. It was twelve files.

Here is the honest fork, before we build anything.

You can write these yourself. They are not complicated, they are tedious, and building them by hand is how you learn what each one is actually preventing. Every engineer should do it once. You will never trust a framework the same way again.

Or you can take mine. They are open source, versioned in git, importable into any agent. Every hour you skip is an hour you do not spend learning something you were going to learn anyway.

I would take mine. I would also read them before I ran them, which is the entire reason for publishing them.

By the end of this post you will have:

→ The twelve foundation skill files, each one and the exact failure it prevents
→ The four-part anatomy every skill file shares: trigger, steps, tools, guardrails
→ How the twelve chain into one loop, so you fix the file that broke instead of the whole prompt
→ The CTO agent I built on top of them, and the four things I will not let it touch
→ The developer kit I install in every repo before I write a line

Here is what is inside.

Table of contents

Why a bigger prompt is not the answer
The anatomy of a skill file
The twelve foundation files
How they chain into one loop
The CTO agent, and the four things it may not touch
The Claude Developer Kit

Before we get into it, a quick heads up: we raise the subscription price every 100 new subscribers. If you have been thinking about going premium, now is the moment. Current subscribers lock in today’s rate for life. After the next 100 subscribers, new subscribers pay significantly more. No tricks, just a real counter. The reason? We are 100xing the value of this publication, and you are going to love what is coming next

$20/month or $150/year. After the next 100 subscribers: $30/month or $195/year. Subscribe now and you keep today’s rate for life.

Inside you get:

→ Every deep-dive in this series: the real files, the configs, and what broke on the way → The paste-ready skills, refreshed as the tools move
→ Early access to what we ship next
→ First look at every future issue

Or you can always invite a friend and earn rewards along the way:

→ 3 friends = 1 month free
→ 5 friends = 3 months free
→ 25 friends = 6 months free

Early builders are already inside.

Shortcut: point an AI at the runtime, github.com/gethouston/houston, MIT licensed, and have it walk you through how the engine loads a skill file. That is the fastest way to see it. Then install Houston at gethouston.ai with invite code getsh*tdone, paste this whole post, and say “import these twelve and show me the loop.”

→ It will pull the twelve files into your agent
→ It will show you which one fires at each step of a run
→ It will fail loudly at the human gate instead of guessing

This post is written to be run, not just read.

The VC's Agent Stack

Mission Control — Mon, 13 Jul 2026 16:15:12 GMT

Hey everybody, welcome back to Mission Control.

Most partners already use Claude, the slow way. A deck lands, you open a tab, paste in the summary, ask whether it fits the thesis, get an answer that could describe forty companies, and close the tab. Then you do it again for the next deck, and the one after that, and by Thursday you have read nine hundred words about a company you will never call back. The model is answering. It cannot see your fund. You are the one carrying the thesis between tabs.

There is a better setup. Six agents, each owning one job in the fund, each stopping at a line you draw. They triage the inbound, source against the thesis, brief you before every first call, draft the memo, watch the portfolio, and write the LP update. The week you spend on the pile becomes the morning you spend on the eleven that matter.

Here is the honest fork before we build, because how much of a fund’s judgment you are willing to route through a machine is a real question, and the wrong answer costs somebody their company.

Felipe’s take: point it at the whole funnel. A seed partner sees thousands of decks a year and writes a dozen checks. Almost all of that work is sorting, and sorting is the thing machines do while you sleep. The agent that reads every deck against your actual thesis, rather than your stated one, gives you back the only thing a partner is short of, which is attention for the founders who deserve it.

Julian’s take: a fund’s edge is its judgment, and judgment is exactly what an agent regresses toward the mean. Train it on the pile and it will learn what a fundable company has historically looked like, which is a machine for missing the next one. The best investments in every fund’s history looked wrong to the pattern.

Where we land: the agent decides what you read. It never decides what you fund. It sorts, it briefs, it drafts, it remembers. Every judgment, every call, every check stays with a person whose name is on the fund. Automate the reading. Keep the conviction.

By the end of this post you will have:
→ One agent stack that turns your fund’s thesis into a working filter, not a slide
→ An inbound triage that reads every deck and surfaces the ones you would have wanted to see
→ A pre-call brief on every founder, waiting for you before the meeting starts
→ Investment memos drafted from your own notes, in your own structure
→ A portfolio monitor that tells you which company changed this month
→ An LP update that goes out on time because it was never late
→ The seven artifacts to send into that chair, one for each agent above

Here is what is inside.

Table of contents

What the VC agent stack actually is
Agent 1, Triage: the pile reads itself
Agent 2, Sourcer: the companies that never sent a deck
Agent 3, Briefer: never walk into a first call cold
Agent 4, Memo Writer: your structure, your notes, your voice
Agent 5, Portfolio Monitor: which company changed this month
Agent 6, LP Update Writer: the letter that was never late
The founder-side kit: What to send into that chair
The guardrail contract, because this stack touches other people’s secrets
The install order, by blast radius
What I will not automate

Before we get into it, a quick heads up. Prices increase once we pass 100 paid subscribers. If you have been thinking about upgrading to premium, now is the moment. Subscribe today and lock in your rate for life. Once we pass 100, Monthly goes from USD 20 to USD 30, and Annual from USD 150 to USD 195. No tricks, just a real counter. The reason is simple. We are building the tools and playbooks that let anyone build and run AI agents, and the value keeps climbing.

USD 20/month or USD 150/year today. No contracts. Cancel anytime. Rate locked for life.

Inside you get:
→ Paste-ready agent builds across fundraising, sales, and GTM
→ The latest tools and updates for building with AI, no code required
→ The Houston build library, refreshed as new skills ship
→ Every future playbook in this series

Or invite a friend and earn your way in:
→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium

Shortcut: paste this whole article into Houston and say “build me the VC agent stack, start with Triage.”
→ It will read your thesis and turn it into a filter
→ It will build the triage rubric and score your inbound
→ It will draft your first memo from your own notes
→ You finish with a working stack, not a reading list

This post is written to be opened, not just read.

Anatomy of an Agent

Mission Control — Sat, 11 Jul 2026 16:01:11 GMT

Hey everybody, welcome back to Houston.

Almost everyone using AI right now is using it as a chatbot, the slow way. You open a model in a tab, describe what you need, copy the answer into another window, and act on it by hand. Want to do it for twenty leads? You do that twenty times. Want last week’s replies pulled and sorted? You go do it yourself and paste it back in. The model is giving you answers, but it cannot see your world, so you are the middleman carrying data back and forth all day.

There is a better setup. Instead of a model that answers, you run an agent that acts. You give it a goal instead of a question, and it decides the steps, uses tools to do the work, remembers what happened last time, and keeps going until the job is done. The afternoon you used to spend copying between tabs becomes one sentence.

This is not a someday capability. The pieces shipped, the open ones and the closed ones both, and every week they get easier to wire together. A chatbot answers. An agent acts. That one line is the whole shift, and inside about 24 months it decides who spends their week on busywork and who spends it on the work only they can do.

This is a guide. We will give you the shape of an agent so it stops being magic, the four parts every single one is built from, how to stand up a starter agent yourself in an afternoon, an honest read on the four things that are genuinely hard, and the harness we built at Houston so those hard parts stop being your problem.

Here is the honest fork before we build, because how much you let an agent actually do is a real question.

Felipe’s take: give it real autonomy. The whole leverage of an agent is that it acts without you. An agent that asks permission for every step is a chatbot with extra clicks. Point it at the work, let it run, and you get back hours a day that no amount of faster typing ever would. This is the single biggest leverage shift available right now.

Julian’s take: autonomy near real systems is risk. The moment an agent can send, pay, delete, or change something a customer sees, a wrong step is not a bad draft sitting in a folder, it reaches the real world instantly. Speed without a gate is how you ship a mistake at machine scale. The guardrails are the point.

Where we land: let the agent run the work, keep the irreversible calls human. The reading, the drafting, the research, the first pass, hand all of it over and let it move. The sending, the spending, anything a person cannot take back, that stays behind a human yes. The agent does the work. You keep the judgment. Build it that way from day one, not after the first mistake.

So that is the boundary. Now the build.

By the end of this post you will have:

→ A clear picture of what an agent actually is, and why a chatbot is not one
→ The four parts every agent is built from: brain, tools, memory, loop
→ Those four parts mapped onto a job you already run every week
→ The afternoon build, so you have a working starter agent you understand
→ An honest read on the four things that are actually hard, and where agents die
→ The gates that keep an agent safe once it can act

Here is what is inside.

Table of contents

What an AI agent actually is
The four parts of every agent
The four parts, on a job you run every week
Build a starter agent yourself, in an afternoon
The four things that are actually hard
The harness: what Houston handles for you
Your first week

Before we get into it, a quick heads up: this publication raises its price every time it passes 100 paid subscribers. If you have been thinking about subscribing, now is the moment. Subscribe before we cross the next 100 and you lock in today’s rate for life. After that, new subscribers pay more. No tricks, just a real counter. The reason: we are working on 100xing the value of this publication, and you are going to love what is coming.

USD 20/month or USD 150/year. Monthly rises to USD 30 and annual to USD 195 once we pass 100 paid subscribers. Subscribe now and pay less, forever. No contracts, cancel anytime, rate locked for life.

Inside you get:

→ Paste-ready agent builds for real jobs: outbound, inbox, research, ops
→ The latest on OpenClaw, Hermes, models, Skills, and Tools, brought down to earth → The Houston agent stack, refreshed as the tooling moves
→ Every future playbook in this series

Or you can always invite a friend and earn rewards along the way:

→ 3 friends = 1 month on us
→ 5 friends = 3 months on us
→ 25 friends = 6 months on us

Early builders are already inside.

Shortcut: open Houston, or your coding agent, and say “help me build my first agent, start with the goal.”

→ It will help you write the goal in one plain sentence

→ It will wire the first two tools and set up the memory
→ It will wrap the whole thing in a loop and run it
→ You finish with a working starter agent, built end to end

This post is written to be built from, not just read.

The Harness Guide

Mission Control — Fri, 10 Jul 2026 16:45:12 GMT

Hey everybody, welcome back to Mission Control.

Here is the setup almost every team is running right now, and most have not noticed how fragile it is. One API key per provider. One UI per model. Zero shared memory between them. And the moment a better model ships, switching means rewriting half the stack: new SDK, new prompt format, new tool wiring. So most teams do not switch. They marry one provider and quietly pay the tax on it. That is the slow way. It works until it does not, and when it breaks, it breaks all at once.

There is a better setup. You put one layer between you and the models that treats every model as swappable compute, keeps your tools and memory in one place, and turns “switch models” from a rebuild into a config change. Not a wrapper around one provider. A harness that any model plugs into.

This is a guide. We will map your lock-in, stand up the engine, wire the routing, put one tool layer under every model, give it memory that survives a model swap, scope your keys and data to your side, run an eval loop so routing is evidence and not vibes, and set up a local model behind the same interface. By the end you will have it running.

Here is the honest fork before we build, because “just pick the best model” is a tempting answer.

Felipe’s take: go model-agnostic and never look back. Models are commoditizing faster than anyone priced in. The frontier lead lasts months, not years, and local models are closing the gap. Betting your whole roadmap on one provider is a bet the current leader stays the leader the entire way. That is not a bet worth making when you do not have to.

Julian’s take: the switching cost is not a vendor problem, it is an architecture problem. If your model choice is welded into your prompts, your tools, and your memory, then “swap the model” touches every layer. Picking the right provider does not fix that. Building the layer that makes the provider a detail does.

Where we land: build the harness, so the model becomes a line in a config instead of a commitment you cannot walk back. Make the model swappable. Keep the layer yours. That is the boundary.

Now the build.

By the end of this post you will have:

→ A clear map of where your stack is locked to a single model provider
→ A harness that runs Claude, GPT, and a local model behind one interface
→ Routing rules that send each task to the right model, with local wired in
→ One tool layer every model reaches, instead of tools wired per model
→ Memory that persists when you swap the model underneath
→ Keys and data scoped to your side, with the model holding neither
→ An eval loop that tells you which model is actually best per task

Here is what is inside.

Table of contents

What a harness actually is Step 1: Map your lock-in Step 2: Stand up the engine Step 3: Route each task to the right model Step 4: Wire one tool layer to every model Step 5: Give it memory that survives a model swap Step 6: Keep keys and data on your side Step 7: Run the eval loop Step 8: Set up a local model Your first harness

👀 Before we get into it, a quick heads up: we raise the subscription price every 100 new subscribers. If you have been thinking about going premium, now is the moment. Current subscribers lock in today’s rate for life. After the next 100 subscribers, new subscribers pay significantly more. No tricks, just a real counter. The reason? We are 100xing the value of this publication, and you are going to love what is coming next 🔥

$20/month or $150/year. After the next 100 subscribers: $30/month or $195/year. Subscribe now and you keep today’s rate for life.

Inside you get:

→ Every deep-dive in this series: the architecture, the exact shapes, and what broke on the way
→ The harness stack and configs, refreshed as the tools move
→ Early access to what we ship next
→ First look at every future issue in this series

Remember! As a premium subscriber you also get every other issue in this series. Here are a few readers keep coming back to:

1️⃣ The Fundraising Agent With 7 Skills
2️⃣ 40 Outbound Prompts
3️⃣ Your Go-To-Market Is Running on 12 Disconnected Tools

Or you can always invite a friend and earn rewards along the way:

→ 3 friends = 1 month free
→ 5 friends = 3 months free
→ 25 friends = 6 months free

Early builders are already inside.

Shortcut: paste this whole article into Claude Code and say “audit my stack for model lock-in, then help me build the harness, starting with mapping where I am welded to one provider.”

→ It will list every place your prompts, tools, and memory are tied to a single model
→ It will rate how hard each one is to swap, and name the abstraction that fixes it
→ It will help you stand up the engine and wire your first routing rule
→ You finish with Claude, GPT, and a local model behind one interface

This post is written to be opened, not just read.

Let’s begin!

The tools we use in this article

→ Claude Code
→ Codex
→ Ollama
→ Composio
→ Houston

1. What a harness actually is

Be precise about what you are building, because the word gets used loosely and only one meaning is the point.

It is not a chat window with a model picker. It is not a wrapper that calls one provider with extra steps. What you are building is the layer that sits between you and every model: an engine that holds the logic independent of any single model, a router that sends each task to the right one, one tool layer they all reach, and one memory store they all share.

The core rule of the whole system is one line: the model decides, the harness does. The model plans and reasons. It never touches your systems directly. Every real action, every tool call, every credential, runs through the harness with scoped access. That separation is the reason the model becomes swappable, because nothing downstream is wired to a specific provider.

In Houston, that engine is a frontend-agnostic Rust core. It does not live inside the app. The desktop app drives it, but so can anything else, over HTTP and WebSocket. The proof it is a real layer and not a wrapper: one of our own products, SmartBooks, is a separate bookkeeping app with its own brand and UI, zero shared interface code, running on the exact same engine in about 400 lines.

Felipe’s rule: you do not need to live in the terminal to own this layer. You need to understand its shape. Describe what your agent does in a short brief and a picklist, and you can build it.

Julian’s catch: the trap is building the harness around one model’s quirks. If your engine assumes a specific provider’s tool-call format, you have built a wrapper, not a harness. Keep the engine ignorant of which model is behind it. That ignorance is the feature.

Get clear that you are building a layer above the models, not a smarter chat, then wire it up.

2. Step 1: Map your lock-in

Here is the step almost everyone skips, and it is the one the whole build stands on.

Before you abstract anything, find where you are welded to one provider. Walk your stack and write it down: your API keys and SDKs, your prompt formats, your tool and function wiring, and wherever context or memory is stored. For each one, note whether swapping the model underneath would be a config change or a rewrite. That list is your lock-in map, and it is the brief for every step after this.

Miss a spot here and it becomes the one thing that blocks a model swap six months from now, right when a better model ships and you cannot use it without tearing something out.

Felipe’s rule: run the shortcut prompt above and let an agent build this map for you. It reads your own setup faster than you will from memory, and it will not flatter you about how portable your stack already is.

Julian’s catch: the deepest lock-in is rarely the API key, it is the prompt format and the tool schemas. Those are the ones people forget, and they are exactly the ones that make a swap a rewrite. Map those first.

Map your lock-in first. You cannot flatten what you have not listed.

3. Step 2: Stand up the engine

Now the layer itself. This is the piece that holds the logic, so everything else can stay swappable.

The engine owns the loop: it takes the task, decides which model to route to, calls tools on the model’s behalf, and reads and writes memory. The models plug into it. The interface plugs into it. Nothing is hard-wired to a provider.

An agent in this world is not a prompt, it is a small, portable definition:

houston.json
{
  "id": "lp-prospector",
  "name": "LP Prospector",
  "description": "Finds target investors and drafts outreach.",
  "icon": "Search",
  "category": "growth"
}

Paired with a CLAUDE.md that holds the instructions, the agent’s actual brief. Group a few into a workspace and you have a team. Because the definition is just files, you can version it, share it, or import it straight from a GitHub repo.

Felipe’s rule: keep the agent as a definition, not a one-off chat. The version you can save and reuse is the version that compounds. A prompt you retype every time is not a system.

Julian’s catch: put the engine behind a clean interface from day one, HTTP and WebSocket in our case. The second the logic can be driven from outside the app, you can point a script, a schedule, or a whole other product at it. That boundary is what makes everything after this portable.

Stand up the engine before the models. The layer is the thing you keep, the model is the thing you swap.

4. Step 3: Route each task to the right model

Picking a model in 2026 is a routing decision, not a marriage.

Different tasks want different models. Long reasoning and code review want a frontier model. High-volume, low-stakes work wants something cheap and fast. Anything touching sensitive data often wants to stay local. Routing is making that choice explicit instead of defaulting everything to whichever provider you signed up with first.

A routing decision looks like this:

task: "categorize 2,000 transactions"     -> local or small model (cheap, private, high volume)
task: "review this migration plan"         -> frontier model (deep reasoning)
task: "draft outreach to 50 accounts"      -> mid-tier model (quality and cost)
task: "anything on regulated client data"  -> local model (never leaves your side)

The harness reads the task, applies the rule, and sends it to the right place. Swap a model out and the rule stays, only the target changes. Local wins when data is sensitive, when volume makes per-token cost the deciding factor, when you need it offline, or when latency matters more than the last few points of quality.

Felipe’s rule: you do not have to choose the one best model. You have to stop sending every task to the same one. Most of your cost and most of your privacy risk come from that single lazy default.

Julian’s catch: route on evidence, not on the vibe. Benchmark it (Step 7) or you will keep paying frontier prices for work a small model does just as well, and shipping sensitive data to an API for work that should have stayed on the machine.

Route on the task, not the hype. A default is not a decision.

5. Step 4: Wire one tool layer to every model

The default in every framework is hand-wiring integrations. Auth, schemas, rate limits, retries, for every tool. You build five and you are done for the week. It also welds your tools to whatever model you wired them for.

The harness flips it: one connector layer, and every model reaches the same tools through it.

In Houston, that layer is built on Composio’s toolkit protocol, which is how you get to 1,000+ tools without hand-rolling 1,000 integrations. Every tool speaks the same interface, so agents discover what is available at runtime instead of being hard-coded to it, auth is handled once and inherited by every agent within the permissions you set, access is scoped to the narrowest reach that does the job, and the same catalog works whether the brain is Claude, Codex, or a local model.

Adding a tool stopped being an integration project. It is a pick from a list, and it works across every model behind the harness.

Felipe’s rule: connect the account once, and every agent you ever build inherits it. That compounding is the whole reason a tool layer beats wiring tools per agent.

Julian’s catch: runtime tool discovery is powerful and it is also where agents get themselves in trouble. Default-deny, then grant. An agent should see the narrowest set of tools and permissions the task needs, never the whole catalog.

Wire tools once, under the harness. Per-model integrations are a tax you keep paying.

6. Step 5: Give it memory that survives a model swap

Most agents have amnesia. Every session starts from zero and you re-explain your stack, your preferences, your rules. When models are commodities, the memory is the compounding asset, so it cannot live inside any one model.

Two things we ruled out early. Stuffing history into the context window: token cost explodes, long-context quality drops, and you pay more for a dumber agent. And retrieval over raw chat logs: it pulls noise, contradictions, and stale facts with equal confidence. Your logs are not a knowledge base.

What we run instead is layered: live session state that is ephemeral by design, a record of what happened and when that you can audit, extracted facts and preferences captured at write time, and the corrections you make once that become defaults. The two decisions that mattered: memory is a write-side problem, so deciding what to keep and what to drop beats clever retrieval, and the store sits in the harness rather than the model, so you swap the model tomorrow and the memory persists.

Felipe’s rule: the correction you make once should stick forever. If you are re-teaching your agent the same preference every week, your memory is in the wrong place.

Julian’s catch: memory quality lives or dies on the write path, not the read path. Write everything and retrieval drowns. Be aggressive about what you refuse to store, and do not mistake a vector database for memory. Storing embeddings is not the same as deciding what is worth remembering.

Keep the memory in the harness, not the model. The asset that compounds cannot belong to a provider you might leave.

7. Step 6: Keep keys and data on your side

This is the part most guides skip, and it is the part that decides whether you can put an agent near real work.

The rule follows from Step 2: the model never holds your credentials, the harness does. The model asks for an action, the harness executes it with scoped keys the model never sees, so a model swap never touches your secrets. On data, the default is local-first: the store lives with the app on your side, so agents wired into real work are not shipping your data to a vendor just to function. Hosted options exist for teams that want them, but data location is a choice you control, not a condition of using the thing. And every action that leaves the building stops at a checkpoint for your approval. Autonomy ends where your name begins.

Felipe’s rule: if adopting an agent means handing a third party your keys and your customer data, that is a non-starter for any serious company. Keys and data on your side is the thing that makes this deployable.

Julian’s catch: “the model never sees the key” only holds if the harness enforces it. Scope credentials at the harness boundary, log every action, and gate anything irreversible behind human approval. Treat the model as an untrusted planner with zero standing permissions, because that is exactly what it is.

Hold the keys at the harness, keep the data local by default. The model is a planner, not a keyholder.

8. Step 7: Run the eval loop

Routing is only as good as the evidence behind it. Without evals, “which model is best” is a vibe, and vibes get expensive.

The loop is simple and you should run your own version. Build a small, real test set per task type, drawn from your actual work, not a public benchmark. Run every candidate against it: frontier, mid-tier, and local. Score on quality, cost, and latency together, not quality alone. Let the winner set the routing rule for that task, and re-run when a new model ships, because the ranking changes more often than you expect. The same loop doubles as a regression check: when you swap a model or change a prompt, the eval catches the quality drop before your users do.

Felipe’s rule: the model everyone is hyping this month is not automatically your best model for your task. Test it on your work before you route to it.

Julian’s catch: eval on your data, not the leaderboard. Public benchmarks are contaminated and they do not look like your workload. A twenty-example set from your real tasks tells you more than any leaderboard, and it is the only thing that makes routing defensible.

Eval on your own tasks, or your routing is a guess. A number you did not measure is a number you cannot trust.

9. Step 8: Set up a local model

Running a model on your own machine used to be a research project. It is now a setting.

Run a local model server that exposes an OpenAI-compatible endpoint. Ollama, LM Studio, and vLLM all do this: pull a model, start the server, and you have a local endpoint on localhost. Point the harness at that endpoint the same way you point it at any provider, because to the engine it is just another target behind the router. Add it to the routing rules for the tasks where local wins, and keep a frontier model wired in alongside it. The point is not local-only. It is local-when-it-wins and frontier-when-it-matters, chosen per task.

Felipe’s rule: local is not the hard-mode option anymore. For a real slice of your tasks it is simply the right one, and it is a setting now, not a project.

Julian’s catch: the OpenAI-compatible endpoint is the whole trick, because it means the harness needs no custom code per local runtime. If your engine can talk to one such endpoint, it can talk to all of them. Standardize on that interface and local stops being a special case.

Point the harness at a local endpoint and route to it. Model-agnostic only counts when local is one of the models.

Your first harness

Here is the order to build it, paced so the foundation is solid before you route anything real.

→ Day 1: map your lock-in. Every place your prompts, tools, and memory are tied to one provider, with how hard each is to swap. Everything downstream is this map made real.

→ Day 2: stand up the engine and wire one model behind it. Get the model-decides, harness-does loop running for a single task.

→ Day 3: add a second model and one routing rule. This is the day the harness earns its name: two models, one interface, a rule that picks between them.

→ Day 4: wire the tool layer and connect one account. Confirm both models reach the same tool through it.

→ Week 2: add memory, add a local model, and run the eval loop on one task. Now it is a standing harness, not a demo.

That is the whole build, and the through-line is the one across this series: keep the layer yours and make the model the swappable part. Map your lock-in, stand up the engine, wire routing and one tool layer, add memory and a local model, then prove it with evals. Most teams will keep marrying one provider and paying the tax. The ones who build this treat the next model release as a config change, not a migration.

Map your lock-in this week, and stand up the engine behind one model.

The bottom line

A harness is one engine that holds the logic, one router that picks the model, one tool layer every model reaches, and one memory store they all share, with your keys and data on your side and nothing welded to a provider. Map your lock-in, stand up the engine, route each task to the right model, wire one tool layer, keep memory in the harness, scope your keys and data, and prove your routing with evals.

The model decides. The harness does. Build that, and the next model release stops being a rebuild and becomes a line in a config.

Your stack is one better model away from a rewrite. Take that risk off the table. Build the harness.

Want us to build your harness with you?

You can build this yourself: map your lock-in, stand up the engine, wire routing and one tool layer, add memory and a local model, and prove it with evals. For a lot of teams that is exactly the right move, and it is the whole point of this post.

If you would rather have it built cleanly the first time, we do it with you. We map where you are locked in, stand up the engine, wire the routing rules for your tasks, connect one tool layer with access scoped safely, set up memory that survives a model swap, and get a local model running behind the same interface, so switching models becomes a config change on day one.

We take on a small number of teams who want this running in days instead of months. On the call we look at your stack and how technical your team is, tell you honestly which parts to abstract first, and tell you what to wire up first.

Book a demo

Just a quick note before you go! This is what your paid subscription gets you, every month:

Early builders are already inside. You are in good company.

We are building Houston, the model-agnostic harness for AI agents, open source under MIT. This guide is how you would build the harness yourself. Houston is that harness, pre-built: the engine, the tool layer, the memory, and the model-agnostic routing, ready to run. Build it yourself from this post, or read the engine and point an AI at it to see exactly how the pieces fit. Either way, you end up owning the layer instead of renting a provider.

Hope this was valuable.

Cheers, Felipe & Julian

Houston. The open harness for AI agents.

How We Run Our Entire Outbound on One AI Agent

Mission Control — Fri, 10 Jul 2026 16:30:37 GMT

Hey everybody, welcome to Mission Control.

Last quarter we sat down to hire our first sales development rep and did the honest math, the kind nobody puts in a pitch deck. Base salary. Commission. A LinkedIn Sales Navigator seat. An email tool. A data provider. Two to three months of ramp before a single meeting hit the calendar. Fully loaded, it came out to roughly $6,000 a month before anyone had said hello to a single lead. The strange part is that almost none of that money was buying skill. It was buying labor.

So we closed the tab and built an agent instead. Today our entire outbound motion runs on one AI agent inside Houston. Not a team, not five tools with an SDR gluing them together at midnight. One agent that surfaces the right people, researches each one, drafts the message in our voice, and hands it to a human for a ten-second review before anything sends. This is not a demo we staged for a post. It is how we run our own growth, in public, every day, and when we walked our community through it in a live workshop, hundreds of people showed up in one sitting.

This piece is the whole thing. The one-time setup, the six-step system, the copy-paste templates behind it, and how to package all of it into a single agent you never have to rebuild. Read it once, then keep it open while you build.

Here is what you will be able to do:

→ Replace the finding, researching, writing, and following-up of an SDR with one agent you supervise for minutes a day
→ Build a target so specific the agent stops wasting messages on the wrong people
→ Turn the people who already engage with you into a clean, on-ICP outreach list
→ Get personalized drafts in your voice, not a template, with a human approving every send
→ Run a follow-up system that books meetings while it teaches itself what works

By the end, you will have the exact six-step system we run at Houston, the copy-paste templates behind it, and a way to turn it into one agent that gets sharper every week.

In this article:

→ The tools you’ll use, and the one-time setup
→ Section 1: Define the target
→ Section 2: Surface the list
→ Section 3: Research each person
→ Section 4: Draft in your voice
→ Section 5: Review and send
→ Section 6: Follow up and learn
→ The copy-paste templates
→ How to know it’s working
→ Run it yourself, or with us

Subscribe now. Pay less, forever.

Before we get into it, a quick heads up: prices increase once we pass 100 paid subscribers. If you have been thinking about upgrading to premium, now is the moment. Subscribe today and lock in your rate for life. Once we pass 100, Monthly goes from USD 20 to USD 30 and Annual from USD 150 to USD 195. No tricks, just a real counter. The reason? We are building the tools and playbooks that let anyone build and run AI agents, and the value keeps climbing. You are going to love what is coming next

USD 20/month or USD 150/year today. No contracts, cancel anytime, rate locked for life.

As a premium subscriber, you get every build we ship after this one, and there is a lot coming: outreach agents, deck agents, the growth agent that replaced our own growth team, and more. Subscribe now and you are in from issue one.

Or you can always invite a friend and earn rewards along the way:
→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium

Short on time?

Copy this entire playbook, paste it into Houston (or Claude, ChatGPT, or Perplexity), and say: “Set this up for me as an outbound agent.” Then come back and read the sections you want to tune. The system is the point. The tool just runs it.

The AI Agent That Runs Your Entire Raise

Mission Control — Thu, 09 Jul 2026 15:31:02 GMT

Hey everybody, welcome to Mission Control.

Most founders already use Claude to fundraise, the slow way. You open a tab, paste in your company details, ask for a list of investors, get a generic answer, copy it into a spreadsheet, then do it all again for the research, again for the intro, again for the follow up. Claude is giving you answers, but it cannot see your raise, so you are the one carrying everything between tabs all day.

There is a better setup. You build one agent, teach it seven skills, and it runs your raise end to end: it builds your investor list, reads each fund before you write a word, drafts the intros, guards your follow ups, hardens your deck, and writes the monthly update that keeps investors warm. The week you used to spend assembling a pipeline becomes a sentence.

This is not a someday capability. The pieces shipped this year, and the rest of this post is how to build it and use it well.

Here is the honest fork before we build, because how much you let this agent do on its own is a real question.

Felipe’s take: let it run wide. A raise is mostly repetitive work stacked on top of building the company, and there are never enough hours for both. The agent that builds the list, does the homework, and drafts every message gives you back the single scarcest thing a founder has during a raise, which is time. Point it at the whole pipeline.

Julian’s take: fundraising runs on trust, and a raise is a small world. A generic or wrong message to a partner is not a bounced email, it is a burned intro you do not get back, and investors talk to each other. The agent can draft brilliantly and still misjudge the one line that matters to a specific fund.

Where we land: the agent drafts everything and a human sends everything. It builds the list, researches the fund, and writes the intro, the follow up, the update. You read it, you adjust the one line only you know, you hit send. Automate the work, keep the judgment human.

By the end of this post you will have:
→ One agent that turns your stage, sector and traction into a precise investor profile → A ranked pipeline of funds that actually write your check size
→ Fund-by-fund research done before you write a single word
→ Intros, follow ups, and monthly updates drafted for your review
→ A deck stress-tested the way a partner meeting would

Here is what is inside.

Table of contents

What the fundraising agent actually is
Skill 1 — ICP: your precise investor profile
Skill 2 — List: the funds that write your check
Skill 3 — Research: read the fund before you write
Skill 4 — Outreach: intros that get replies
Skill 5 — Follow-up: never let a warm reply die
Skill 6 — Deck: stress-test like a partner meeting
Skill 7 — Update: the monthly that compounds
How one agent runs all seven
Your first week

USD 20/month or USD 150/year today. No contracts, cancel anytime, rate locked for life.

This is the very first playbook in the series. As a premium subscriber, you get every build we ship after this one, and there is a lot coming: outreach agents, deck agents, the growth agent that replaced our own growth team, and more. Subscribe now and you are in from issue one.

Or you can always invite a friend and earn rewards along the way:
→ 3 friends = 1 month of premium
→ 5 friends = 3 months of premium
→ 25 friends = 6 months of premium