HtAG Analytics runs its own business on Morpheus.
Before Morpheus was sold to anyone, it ran the company that built it. HtAG Analytics operates customer lifecycle, product feedback, engineering handoff, revenue reporting, support triage, enterprise responses, market intelligence and follow-through on the same layer — across the tools it already used. The product thesis came out of that pressure, not out of a deck.
One company, on the layer, before anyone else was asked to.
Four numbers, including the one that counts against us. A vendor who will not run their own product on their own business is telling you something — and so is a vendor who hides what that proves.
Why this is worth reading
Demos are clean. Operating companies are not. What follows is the unglamorous half: billing anomalies, stalled onboardings, duplicate bug reports, follow-ups that would otherwise die in a thread, and credential checks nobody enjoys running.
Why it is labelled customer zero
Customer zero means our own business ran on the product first. Every workflow on this page carried real operations before any client conversation — the label tells you exactly what you are reading: the deployment we know best, published in full.
Five moments a business will recognise.
Not features. The specific points where work usually leaks — and what the operating layer does at each one instead.
Someone reports a bug in a message thread. It is the fourth report of the same thing, and nobody knows that.
The report is checked against what is already open, what shipped last, and what regressed. If the error context is missing it asks for it. The output is a build-ready issue with the evidence still attached — not a fifth duplicate.
A new user stalls halfway through onboarding. It surfaces a month later as churn.
Product state, lifecycle state and communication rules are read together, and the next customer action is prepared. It waits for approval before anything is sent.
A buyer asks a security question that was answered well six months ago, by someone who has since moved on.
The answer is assembled from previously approved positions and current product evidence, with internal assessment kept separate from customer-facing language. The institutional memory outlives the person who built it.
A competitor changes the language of the category. The company keeps using last year’s words for another two quarters.
The shift is recorded against the positioning memory, so the next deck, page and answer stop repeating a claim that has gone stale. Being wrong once is a mistake; staying wrong is a memory problem.
A follow-up is agreed in a thread on a Thursday. It is never mentioned again.
It becomes a held obligation with a time attached and comes back when it is due. It can also decide not to interrupt when the context says silence is the better call.
The work it actually carries.
Each one names when it happens, because cadence is the difference between something that runs and something that was demonstrated once.
Customer lifecycle and product telemetry
Product usage, billing state, onboarding progress and account anomalies read together, then synced into the lifecycle system so segments reflect what people actually did.
DailyProduct feedback into engineering work
Reports classified as new, duplicate, regression or already shipped, with evidence preserved and deployment state checked before anything becomes a tracked issue.
On every reportRevenue and operating rhythm
Revenue and growth reporting on a fixed cadence into the channel the team already reads. The numbers arrive with interpretation and the questions they raise.
Daily and weeklySupport and incident triage
Classification before root-cause work, read-only investigation, and impact verified against the record before any credit is discussed with a customer.
On escalationEnterprise sales and security answers
Buyer questions answered from previously approved positions and current product reality, with the internal assessment kept separate from what goes to the customer.
On requestMarket intelligence and positioning memory
Category and adjacent-platform movement tracked, classified, and written back into positioning memory so the next piece of collateral does not repeat a stale claim.
MonthlyFollow-through that does not decay
Obligations, prospect follow-ups and scheduled reversions held as memory-backed commitments with a return time, rather than as messages someone hopes to re-read.
ContinuousSystems and credential monitoring
Service health probed on a short loop and credential hygiene on a long one, with exceptions routed to the right channel instead of a dashboard nobody opens.
Every 4 hoursTwenty-one systems. None of them replaced.
This is the homepage architecture diagram with the real names filled in. Every system below stayed exactly where it was; the layer above connects the work that happens around them.
Operating memory · evidence · approvals · routing · artifacts
- Slack
- Slack Lists
- Email and branded sending
- Developer Portal DB and API
- Customer.io
- Stripe
- WordPress membership stack
- Circle
- GoHighLevellegacy, not source of truth
- Google Analytics 4
- Google Search Console
- Google Ads
- GitHub
- Claude Codegoverned engineering path
- AWSread-only plus IaC-governed change
- Model providers
- Operating memory store
- Bright Data
- HtAG Intelligence MCP
- Langfuseread-only inspection
- Shared documentswhen explicitly wired
Systems of record remain authoritative
This is not a connector catalogue
These are the surfaces one operating company actually runs across. Some are live scheduled automations, some are read-only tools, and some are source systems used inside particular workflows. Do not read the list as a claim that every one ships as a productised connector today.
No migration was required
Not one of these systems was replaced to make the layer work, and none became a dependency of it. That is the same claim made on the homepage — this is the instance where it was tested first.
Ten things that happen whether anyone asks or not.
The tightest loop runs every four hours. Recurring work is the least impressive and most convincing evidence that something is in production rather than in a demo.
Service health
- Health check across services
- API probes against live endpoints
Money and usage
- Revenue reporting
- Developer Portal delta
- Developer Portal API usage
- Customer lifecycle sync
Growth and market
- Growth report
- Commercial market scan
Intelligence and hygiene
- Vertical AI digest
- Credential and secret health
Constraints that came from being burned, not from a template.
Each of these exists because the alternative was a live risk in a real business. They read awkwardly on purpose — specific rules usually do.
Never acknowledge fault before the record supports it
A customer gets a response quickly. It does not concede a cause until the investigation says so.
Verify real impact before discussing credit
Compensation conversations start from what the record shows happened, not from what was reported.
Infrastructure changes only through infrastructure-as-code
No ad hoc mutation of production, regardless of how small the change looks.
No mailbox scanning without approval
Access to a person’s correspondence is asked for each time, not assumed from an earlier grant.
No customer credential changes unless explicitly instructed
An account action that affects a customer’s access is never inferred from context.
A pre-flight check before anything externally visible
Read-only work runs freely. Anything a customer or the public could see stops for a check first.
Money, production infrastructure, customer communication and outbound sending are all on the far side of a human. The layer prepares, routes, remembers and monitors. It does not decide those four.
Six things we will not say about ourselves.
Published because the interesting question is never what a vendor claims. It is which claims they had the chance to make and did not.
Not “fully autonomous company operations”
People decide anything involving money, production, customers or outbound. That is a design position, not a temporary state.
Not “every system has a shipped connector”
The surface list is an account of how one company operates, not a product capability matrix.
Not “it replaces your CRM or analytics”
It sits above the stack. Every system named on this page is still doing its job.
Not “all actions are automatic”
A large share of the value is work that is prepared and then deliberately parked.
Not “the internal memory is all productised”
Some of what runs here is ahead of what is generally available, and is labelled that way in the capability list.
Not “complete context across every private system”
Scope is granted per system and per workflow. Nothing is assumed readable because it is technically reachable.
Customer zero proves the product carries real commercial work under real operating pressure, built by the team that has to live with the consequences. It does not prove that an unrelated organisation reached the same result. That is what the three client workflows on the case studies page are for, and it is why they carry a different label.
Two of these, taken apart node by node.
This page is the breadth. The two teardowns are the depth — one event-driven, one scheduled — published with their gates, their stop conditions and their current state.
Research intake to reviewed draft
A paid request becomes a research package and a draft. Two hard gates, and a person on the release.
Read the teardown → ScheduledMarket intelligence learning loop
Signals move through four evidence tiers. Twelve hypotheses open, none validated — and it says so.
Read the teardown →What people ask about customer zero.
Including the question a sceptical buyer should be asking.
Is the company run autonomously by the operating layer?
No. Money, production infrastructure, customer communication and outbound sending all sit behind human approval. The operating layer prepares, routes, remembers and monitors. People decide.
Are all of these systems shipped Morpheus connectors?
No. They are the surfaces the customer-zero operation actually runs across. Some are live scheduled automations, some are read-only tools, and some are source systems used inside particular workflows. It is an operating account, not a connector catalogue.
Why publish the constraints rather than the capabilities?
Because every operating layer can list capabilities, and the list is rarely the thing a buyer is worried about. What a system refuses to do without asking is harder to fake and more useful to know before you deploy it.