Skip to content
TechFabric
GTM Brain

Agentic GTM · Our own product

Running our own go-to-market on a Databricks App

A signal-driven outbound system on Databricks with durable workflows, governed autonomy and human approval gates. It runs TechFabric's own pipeline, which is why we can show it working.

Production

Databricks App in the workspace

Per-tenant

Isolation enforced in the data layer

Every send

Revalidated at delivery

Client
GTM Brain
Sector
Agentic GTM · Our own product
Stack
Databricks AppsLakebaseUnity CatalogTemporal

We pointed it at our own pipeline first

If an agent sends a bad email to one of our prospects, we lose the prospect. That constraint changed how we built this in ways a client project never would have.

GTM Brain is the system that runs TechFabric's outbound. It watches for signals, keeps a memory of every account, decides who is worth writing to and why the trigger fired this week, drafts from whatever the actual trigger was, and adjusts on what comes back. It is a Databricks App running in the workspace, with everything that implies about permissions and uptime.

What took the time

Drafting a plausible email is the part that demos well, and most demos stop there. It was maybe a fifth of the work.

Durability. A pass can run for hours. If it dies halfway, the failure mode is not an error message, it is a contact marked as messaged when nothing went out, or messaged twice because a retry lost its place. Both are worse than never running. Temporal holds the workflow state, so a step that fails at three in the morning picks up where it stopped, and afterwards you can read exactly what happened.

Governed autonomy. Routine actions run on their own. Publishing, launching and sending do not. Those need a tenant-issued grant that is scoped to the capability and expires, and every send gets revalidated at the moment it goes out, whatever was true when it was approved. Ten minutes is long enough for an account to be marked do-not-contact. The enforcement lives in the pipeline, because a prompt asking a model to behave is not a control.

Memory that outlives the process. Account state sits in Lakebase. An agent whose memory is a context window forgets the account between runs and then relearns it badly, which is how you end up introducing yourself twice.

Isolation. Every organisation's data is scoped in the data layer, not filtered in application code. A missing WHERE clause in application code is a leak; in the data layer it is a query that returns nothing.

Approval that survives a deploy. A workflow can wait days for a human signal and resume from exactly where it paused. Approval gates that a deployment resets are decoration.

Why this is a case study and not a product page

The shape generalises. Swap outbound for claims triage, underwriting review or contract intake and the architecture holds: signals in, judgement under policy, durable execution, an audit trail, and a person holding the switch on anything that leaves the building.

It also answers the question we get asked more than any other, which is whether we have actually put one of these into production. We can open the workspace and show you one doing something we depend on.

The Databricks part

The agents need governed access to real data. The workloads belong next to that data. And somebody's security team eventually has to be able to follow what happened.

Unity Catalog decides access. The App runs in the workspace under its own service principal. Nothing leaves the boundary to be reasoned about somewhere else.

That is the same pattern we bring to client work, tested first on the system where a mistake costs us our own pipeline.