The Architect: a campaign, stage by stage

The Architect plans a whole campaign on top of HubSpot, one stage at a time. It sits first under Messaging. The chat on the left asks what the account cannot answer for itself; the plan on the right fills in as you answer, one section per stage. Each stage is proposed by the Architect, edited or confirmed by you, and the next stage reads only what you confirmed.

The stages

1. Brief. What the campaign is for, the number, what it is centred on, who it is for (your targets from Identity), the kind (nurture, scheduled, alert) and the rollout (first or follow-up). The chat fills this form; you can type into it directly.
2. Research and analyze. The Architect reads the account in full before it proposes anything: the identity framework and target cards, hubs and articles, evidence, pools, templates, blocks, senders, what moved after past campaigns, prior plans, and HubSpot live (contacts per target, lists, workflows). It reports what you have, what is in progress, what is missing and which pillar it leaves bare, what worked, risks, and what that means for this campaign. Nothing is proposed yet. Every line carries the read it came from, like R4.
3. Campaign suggestion. The argument per target (what they believe now, what they must believe), then the rows in cascade order: the pool each row uses or creates, its type, who it admits (a HubSpot filter you can open and change), how many contacts that admits today, how many messages and their arc, which rows are priority, the pace between sends (set in the flow or the HubSpot workflow, never on the campaign), and the content the plan needs that the account does not have.
4. Templates and blocks. Which template each pool sends on: one from the account, or a design from the library when none in the account has the sections the argument needs. Per block section, the plan: each message carries its own content, or a Block fills it on this row (an existing Block by name, or one the build creates), with its mode (sequential, fixed, rotational). Variants only where the blocks differ by audience within a row, checked in order, first match wins; a variant that can never apply is refused on confirm. The stage ends with the list of Blocks the build creates.
5. Content. The brief per piece of content the plan needs: the reader's situation, the one belief it moves, the pillar and target, the row and message it serves, the claims it cites from the evidence library (or the gap it names), the outline, the call to action, and what already exists on the subject. Reuse comes first: a live article that carries the pillar for the same target is linked, not rewritten. Pieces are drafted after Go, land as Drafts, and a person publishes; a message that links to a piece waits until it is Live.
6. Setup HubSpot. See below.
7. HubSpot automation. See below.

Event arcs

When a chosen target gathers at an event in the next 90 days (Identity, Events), the suggestion builds the campaign on it. Three phases, each a scheduled row on the event's dates: seeding (six to one weeks before), event (the event days), follow-up (one to four weeks after). Your part sets the arc: exhibit or speak gives the full arc with a second follow-up row for the show's leads (the Architect asks which HubSpot list or form holds them); attend gives seeding and follow-up; none means the audience is there and you are not, so nothing implies attendance. The event shows on the campaign page; each row's phase shows in its type.

Setup HubSpot

Run the check once Templates and blocks is confirmed. It reads the portal (no AI, no tokens) and lists what this plan needs that is not there, each line ticked or not:

• The mxAURA property group and the mxa_ contact properties the templates read at send (mxAURA writes them at dispatch). mxAURA's own, ticked.
• Customer properties the row filters reference that the portal does not have, with the options the filter names. The customer's own, unticked: create one only if it is theirs to have, and someone must also populate it, or the rows admit nobody. An existing property with options the filter names but the portal lacks is reported; Setup never edits it.
• One enrolment list per row, dynamic, built from the row's filter, where the connection holds crm.lists.write (every new connection does; an older one grants it with one Reconnect, which a banner asks the owner for) and the filter can be said as a list. Otherwise the line says why, and the automation enrols from the filter instead.
• The marketing email per template and the workflow: reported here, created in later drops.

Tick what you want, press Create in HubSpot, and the ticked, missing items are created. Create only: nothing existing is renamed, deleted or changed. Each creation is recorded in Activity with the plan. Check again re-reads the portal and keeps your ticks. Confirm the stage when the list says what you mean. Working in a client account as the agency, the check runs but creating is the client's to do.

HubSpot automation

Run it once Templates and blocks is confirmed; run it after Go if you want the button, because the automation points at the campaign the build makes. It reads the portal: the tier (workflows, or not), and the mxAURA loops already there. Then the automation pack recommends, in words you check against HubSpot: what enrols (the row filters as one filter, a list, or by hand), the steps in order, the branch per Status and Code (Message sends and loops; Skip ends; Error notifies and ends; Hold ends), the delay that carries the plan's pace, and when to change an existing loop rather than make a second.

On Marketing Hub Professional and above the dry run shows the exact workflow body the button creates. Its shapes (the app actions, the branches, the delay) are taken from a loop that already works in the portal, read and adapted: this campaign's id in the app action, this campaign's emails in the send actions, the plan's pace in the delay, this plan's enrolment, a new name, disabled. A portal with no working mxAURA loop yet has no reference to adapt, so the button waits (spike A settles the shapes for every portal); make the first loop by hand from the recommendation. Create the workflow, off creates it disabled; open it in HubSpot, check each branch, and turn it on after the Go-live check. If the portal already has a loop for this campaign, the button refuses a second unless you say so.

On Starter there are no workflows. Make the flow and form makes an email-only form in the portal and a flow in mxAURA on this campaign, paced by the plan's days between sends, sending through that form. You set the form's follow-up email in HubSpot (the Automation tab), verify the flow once, then activate it. Nothing is enabled or verified by the Architect.

Go

Go, at the bottom, lights when Templates and blocks is confirmed. It shows the bill first: what it makes (the campaign and its rows, pools created, adapted or reused, Blocks, messages the Composer drafts, content pieces), about how many tokens that spends against the month's allowance, and what will hold. Then it builds, in mxAURA, through the same routes the buttons use: folders named for the campaign; the campaign, off, with no timing of its own; the pools; the rows in cascade order with their filters and priority; the Blocks the plan names (empty; their entries are yours to write on the Blocks page); the bindings and variants per row. Then it queues the Composer once per pool it can compose on (an account template with its field types set) and a draft per new content piece; both run in the AI Queue and land as Drafts. A person makes each message Ready and publishes each piece. The review runs over the whole plan before the first Go.

Everything Go makes is recorded on the plan, so Go again fills what is missing (a pool the queue could not take, a piece added later) and never makes a second campaign. The Build section lists what was made, what was queued, and the holds: a pool on a library design (its HubSpot email comes in a later drop), a reused pool (not rewritten), Blocks waiting for entries, a message that waits on a piece not yet Live. The Go-live check on the campaign names those pieces until they are published. Nothing is enabled, published or sent by the Architect. Working in a client account as the agency covers the plan up to Go; the build is the client's to run.

The template library

When no template in the account has the sections the argument needs, the Templates stage proposes a design from the library: Letter (hero, opening, argument, close), Brief (hero, summary, argument, proof, close) or Notice (headline, what changed, what to do, close). Each is a HubSpot email in HTML that reads the mxAURA tokens (subject, preview, sender, the numbered content fields, the tracking pixel) and declares its sections and typed fields, so the import reads them as they are.

Once the stage is confirmed, Create in HubSpot and register creates the marketing email in the portal from the design and registers it here as a template, named for the design, with the sections the plan uses as Blocks marked reusable (so the Blocks and bindings have their kinds). Once each: an email or template of the same name is reused, never made twice. The stage then points those rows at the new template, and Go again composes their messages. The stages after Templates go stale, since they read the new template.

A portal that refuses the email (some Starter portals may) keeps HubSpot's message on the stage; Download the HTML gives you the design to import by hand in HubSpot, after which you import the email under Templates as usual.

The review

The review runs when you confirm the suggestion, the templates or the content, and again before Go. It reads the plan as it would stand with that stage confirmed and checks it against the standing rules: no span no claim, no manipulation, reuse before creation, rows when the pool differs and variants when only the blocks differ, the pace stated (a warning when it is not), every row admits someone, nothing enabled. It refuses or passes, each refusal with the stage, the line (the row, variant, claim or brief), the rule, and what would satisfy it. A refusal keeps the stage proposed with your edits; fix the line and confirm again.

Some refusals are certain (code checks them): a row that admits nobody, a second row of a pool that can never send, a variant that can never apply, a brief with no claim and no gap. Those cannot be confirmed past. A refusal the model made on judgment can: Confirm despite the review names the lines and records the override in Activity. Warnings never block. The review goes stale when any stage changes after it, and runs again on the next confirm.

Editing and confirming

The form is the truth. Change a line, a row, a filter or a number and press Save; press Confirm when the stage says what you mean. Confirming opens the next stage and lets it run. Editing or re-running a confirmed stage marks every stage after it Stale: re-run those, or confirm them as they stand if the change does not touch them. Unconfirm takes a stage back to proposed.

A row's filter opens in the same filter builder as a campaign row. A filter edited by hand shows not counted until the stage is re-run.

From an assistant

The Architect is on the mxAURA MCP server and the API (/v1/architect/*). An assistant connected to your account can start a plan, talk to the Architect, run and confirm stages, read the bill and press Go, with the same rules as here: the review refuses the same lines, nothing is enabled or published, and plan bodies carry briefs, rows and filters, never message bodies. Reading a plan needs campaigns.read; changing one campaigns.write; the model stages and Go ai.write (Go also needs campaigns.write). The Developer Center has the routes and the tools.

Plans

A plan keeps every version of every stage. Pick a plan at the top left or start a new one. Deleting a plan removes its stages and history; nothing built from it is touched.

Cost

Research and each stage use your AI allowance, metered as architect. The account reads behind research are kept for a day, so re-running a stage the same day does not read the account again unless you ask for a fresh read. The platform chooses the model per stage; the planning stages run on the strongest model available.

All topics