Building on Solid Ground — NurtureHub's Background Job Foundation

v1.0.40 | Engineering Update

Every email that NurtureHub writes, every CRM record it syncs, every intent score it calculates, and every hot lead alert it fires happens in the background — silently, reliably, and without the agent ever needing to think about it. That "background" is what v1.0.40 is all about.

Why background jobs matter

NurtureHub's promise to UK property agents is radical simplicity: assign a contact to a category, and the platform handles everything else. Delivering on that promise means the platform needs to do a lot of work — AI calls, CRM writes, engagement tracking — without making the agent wait for any of it.

Background jobs are the mechanism that makes this possible. When an agent assigns a contact as a "Landlord", that action immediately returns a response to the UI. Behind the scenes, a durable background job picks up the event and orchestrates the full sequence — resolving the agency's brand voice, calling the AI, storing the three-email sequence, and syncing it to the CRM — across multiple steps, with retries if anything goes wrong.

What we built in v1.0.40

This release lays the foundational infrastructure that every background process on the platform runs on. It is built on Inngest, a durable workflow engine designed for exactly this kind of AI-heavy, multi-step job orchestration.

A shared event schema contract

The first thing we established is a consistent event naming convention and validated payload schema for every event the platform emits. Events follow a domain/action pattern — nurture/sequence.generate, crm/sync.push, lead/intent.score — so that any engineer reading a log or a queue can immediately understand what is happening and why.

Every payload is validated with Zod at the point of emission. This means malformed data is caught immediately, TypeScript types are inferred directly from the schema, and the agents consuming events downstream can trust what they receive without defensive coding.

Fair resource allocation with per-tenant concurrency

NurtureHub is a multi-tenant platform serving many agencies simultaneously. A single agency importing five hundred contacts at once should not delay another agency's hot lead alert from firing. Per-tenant concurrency limits solve this: each agency's jobs run in their own concurrency lane, keyed on their tenant ID. Jobs that exceed the limit are queued, not dropped, and execute in order as capacity frees up.

Resilience through exponential backoff

AI APIs have rate limits. CRM webhooks occasionally time out. Databases have bad moments. Rather than failing silently or requiring manual intervention, every Inngest function on the platform retries failing steps automatically using exponential backoff.

Critically, retries happen at the step level. If a five-step agent function completes four steps successfully and fails on the fifth, only the fifth step is retried — the previous four are not re-executed. This makes the pipeline safe to retry without risk of duplicating emails, CRM writes, or any other side effect.

Shared step utilities for every agent

The last piece is a library of shared step utilities that every agent function imports. Rather than each AI agent reimplementing how to resolve a tenant's brand voice, construct a CRM client, or emit a follow-on event, these are all handled by shared utilities with consistent behaviour. This keeps individual agent implementations focused on their specific logic and eliminates drift between agents.

What this enables

This infrastructure release does not change anything visible to agents using the platform today. What it does is provide the reliable, consistent foundation that every AI capability NurtureHub delivers depends on — from the first nurture sequence generated to the thousandth hot lead alert fired.

Every feature built from this point forward runs through this foundation.

---

Read the full technical documentation in the Inngest Background Job Foundation feature guide.