A stack diagram should explain jobs, not logos
AI GTM stacks become confusing when every product is described as an all-in-one platform. The useful question is which system owns each job in the signal-to-action loop.
The same product can cover several jobs, and the right boundary depends on your team. What matters is that context has a source of truth, business rules are inspectable, model tasks are bounded, customer-facing actions have controls, and someone can tell when the workflow fails.
I use n8n, Claude, HubSpot, GitHub Actions, Snowflake, SQL, and custom code in my own work. Clay is included here as a researched enrichment and GTM-workflow category, not as a claim about my personal production stack.
Start with the seven jobs
1. System of record
The CRM owns accounts, contacts, opportunities, activity, lifecycle state, and responsibility. For many B2B SaaS teams that means HubSpot or Salesforce.
Do not treat the CRM as an infinitely flexible compute engine. Keep operational fields and actions there while moving heavy transformations and historical analysis to systems designed for them. HubSpot's developer documentation is the contract when workflows read or write through its APIs.
2. Trusted analytical context
A warehouse and data models establish reusable definitions across product, marketing, sales, and finance data. Snowflake plus SQL fills this role in parts of my work.
This layer should answer what a record represents, how identities resolve, which timestamp controls recency, and why a metric can be trusted. Without it, every automation invents local definitions.
3. Enrichment and external signals
Enrichment platforms assemble firmographic, people, intent, and research data from external providers. Clay is prominent in this category and publishes practical material through Clay University.
Use enrichment after deciding what decision the new field will change. More columns create cost and maintenance even when nobody uses them.
4. Orchestration
n8n connects triggers, APIs, transformations, branches, schedules, and delivery. Its visual workflow makes cross-system logic easier to inspect, while code nodes and sub-workflows provide escape hatches.
Define retries, idempotency, credentials, ownership, and error workflows. n8n documents dedicated error-workflow handling because production automation needs a failure path.
5. Model tasks
Claude and other language models handle work where language and ambiguous context matter: classification, extraction, summarisation, research, and drafting.
Treat the model as a component with a defined input and structured output. Anthropic's tool-use overview shows the same contract-first idea for model tool calls.
Keep deterministic rules deterministic. Ownership, consent, suppression, permissions, and exact calculations should not depend on model interpretation.
6. Custom compute and applications
GitHub repositories, application hosts, serverless functions, and small internal apps handle logic that deserves tests, version control, a custom interface, or more control than a workflow canvas provides.
GitHub Actions is useful for scheduled jobs that already live beside code, secrets, and logs. It is not an exact-time scheduler. GitHub's workflow troubleshooting documentation warns that scheduled events can be delayed during high load and may sometimes be dropped.
7. Action and observation surfaces
The output belongs where a user can act: CRM queues, tasks, Slack, a sequencer, or a purpose-built dashboard. Separately, operational state belongs in logs and monitors.
Do not confuse an alert surface with a monitoring system. Slack can tell you that something failed. A monitor should also tell you what was expected, what never started, what is late, and what can be rerun.
Where n8n fits
n8n is strongest when a workflow spans several APIs and the team benefits from seeing the control flow. Examples include inbound enrichment, account research, reply classification, CRM writeback, and scheduled summaries.
Move logic out when it becomes difficult to test, reuse, review, or observe. A practical boundary is to keep orchestration in n8n and put complex domain logic in version-controlled code or trusted data models.
See seven n8n GTM workflows for concrete designs.
Where Claude fits
Claude helps when the input is unstructured and the output can be evaluated. Good tasks include extracting objections from calls, converting notes into structured account context, classifying replies, and generating a research brief with evidence.
It is also a building tool. Claude Code helped me move from analytics specifications to working applications and workflow code. That does not remove engineering responsibility. Generated code still needs tests, permissions, deployment, monitoring, and a human who understands the failure modes.
Where Clay fits
Clay is most relevant when external data assembly, enrichment, and research are central to the workflow. It can reduce the work required to combine providers and prepare account or contact context.
Evaluate it against a defined use case:
- Which fields or signals are unavailable internally?
- What action changes when the data arrives?
- How fresh must it be?
- What is the cost per useful action, not per enriched row?
- Where will consent, suppression, and regional requirements be enforced?
- Which system retains the source and timestamp?
Do not buy an enrichment platform to compensate for an undefined ideal customer profile or an unclear outbound motion.
Where HubSpot fits
HubSpot should remain the operational source of record when it already owns the team's customer and prospect workflow. Write back the minimum context a user needs, preserve ownership and history, and avoid creating fields that only an automation understands.
When a workflow updates records, design for duplicate events, partial failures, rate limits, and replay. An idempotent update produces the same safe result if the same event is processed twice.
Where GitHub Actions fits
GitHub Actions is useful for code-based daily refreshes, scheduled extraction, report generation, and repository-native maintenance. It provides versioned workflow files, secrets, logs, and manual dispatch.
Add an external or independent watchdog for business-critical schedules. My own monitor tracks expected jobs across seven repositories and remaining Trigger.dev workflows because a missing run is otherwise easy to confuse with “nothing happened today.” Read the full monitoring pattern.
A reference architecture
For an account-prioritisation workflow:
- Warehouse models combine fit, product, engagement, and activity data.
- A scheduled job calculates eligible accounts and explanations.
- Enrichment runs only where important context is missing.
- Claude creates a bounded research or activity summary.
- Business rules apply ownership, suppression, and review requirements.
- HubSpot receives the priority, explanation, timestamp, and action.
- A queue or dashboard shows the user what to do.
- Outcomes and corrections return to the warehouse.
- A monitor checks that every expected run completed.
Each component has a clear job. Replacing one product does not require redefining the entire operating system.
The minimum viable stack is often smaller
A first workflow may need only a CRM, n8n, one model API, and a small database or spreadsheet. Add infrastructure once the workflow proves itself and its failure modes demand it.
The standard is whether the right user receives trustworthy context, can take the right action, and can recover when the system fails. The broader AI GTM engineering guide shows how to design that loop before choosing products.