HtAG Analytics was the first business to run on Morpheus. Customer requests, product feedback, research and engineering handoffs move across its existing tools with their context attached. This operating record shows how eight parts of the business use the same layer to prepare work, retain decisions and follow through.
8
operating domains
21
systems in the customer-zero operation
10
recurring automations
Chapter 01 / 06
Operating scope
The company ran its own operating layer before asking another organisation to rely on it.
One company, on the layer, before anyone else was asked to.
These figures describe the operating scope of HtAG Analytics, the customer-zero business behind Morpheus.
8operating domains carried on the layer
21systems it works across, unchanged
10automations on a recurring schedule
4htightest recurring loop — our own business, live
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 recurring situations show how evidence, prior decisions and approval context change the next action.
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.
Eight domains run across twenty-one existing systems while the systems of record remain authoritative.
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.
Daily
Product 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 report
Revenue 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 weekly
Support 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 escalation
Enterprise 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 request
Market 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.
Monthly
Follow-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.
Continuous
Systems 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 hours
Twenty-one systems, connected above the record.
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.
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 scheduled automations and operating rules carry routine work and preserve the boundaries learned in practice.
Ten recurring automations carry the routine work.
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.
Every 4 hours
Service health
Health check across services
API probes against live endpoints
Routes to: the engineering channel, exceptions only.
Daily
Money and usage
Revenue reporting
Developer Portal delta
Developer Portal API usage
Customer lifecycle sync
Plus: a continuous heartbeat that reports state and stays quiet when it should.
Weekly
Growth and market
Growth report
Commercial market scan
May not: act on what it finds. Reports land with people.
Monthly
Intelligence and hygiene
Vertical AI digest
Credential and secret health
Plus: one-shot reminders and scheduled commercial reversions where a date was agreed.
Controls learned through operating experience.
Each rule responds to an operating risk encountered in the business. It gives the workflow a clear boundary and the reviewer a specific check.
Establish the cause from the record
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.
Approve mailbox access each time
Access to a person’s correspondence is asked for each time, not assumed from an earlier grant.
Require an explicit instruction for credential changes
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.
The case defines what can be reused from customer zero and where its evidence stops.
The scope of the customer-zero evidence.
Read the operating figures together with the authority, availability and access boundaries that apply to this deployment.
People retain consequential authority
People decide actions involving money, production, customers and outbound communication.
An account of the systems in use
The list describes HtAG’s actual operating surfaces. Connector availability is confirmed for each engagement.
Existing systems stay authoritative
It sits above the stack. Every system named on this page is still doing its job.
Prepared work reaches its reviewer
A large share of the value is work that is prepared and then deliberately parked.
Availability follows the capability status
Internal deployment and general availability are distinct stages. The capability list records the status applicable to each.
Context follows explicit permissions
Scope is granted explicitly for each system and workflow.
Disclosure
Customer zero demonstrates commercial work inside the business that builds Morpheus. Outcomes in other organisations require their own evidence; the three client workflows on the case-studies page carry separate delivery labels.
What became reusable?
The retained client context, workflow state, evidence and approval history became reusable across HtAG’s recurring work. The value is in beginning the next run from that prior position, then updating it as the business changes.
This is customer-zero evidence from the business that builds Morpheus. Delivered client workflows carry their own status and operating facts.
Two node-by-node cases and the FAQ expose gates, stop conditions and connector scope.
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.
The operating scope, review points and evidence a buyer can inspect.
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. The case records how those surfaces are used in this operation.
How should a buyer read the operating boundaries?
Read each capability alongside its permissions, human approval point and delivery status. Those boundaries explain what a workflow may do in practice.