Pre-SaaS · Local-first · Twenty-client capacity

The operating system
behind the offer.

A practical service-delivery architecture using Hermes Agent as orchestrator, Obsidian as the human control room, PostgreSQL as canonical memory, local models for repetitive work, and a frontier API only when complexity justifies it.

The governing decision

Intelligence layer, not database.

Hermes, Obsidian and the language models should coordinate and interpret the operation. They should not become the canonical CRM, the compliance ledger, or an uncontrolled outreach engine.

DO

Use agents to decide and coordinate

Plan jobs, classify messy text, prepare briefs, draft communications, surface exceptions and improve playbooks.

STORE

Use PostgreSQL as truth

Keep people, properties, permissions, campaigns, activities, scores and audit history in a structured transactional store.

CONTROL

Require explicit gates

Outreach, record mutation, deletion, exports and cross-client access must pass deterministic rules and scoped permissions.

Reference architecture

A local-first, periodically connected control plane.

01 · INTERFACE

Obsidian + dashboard

Client manuals, operating notes, campaign decisions, briefs and exceptions.

02 · ORCHESTRATION

Hermes Agent

Schedules workflows, invokes tools, creates queues and escalates uncertainty.

03 · INTELLIGENCE

Local + frontier models

Cheap batch classification locally; complex reasoning through API escalation.

04 · EXECUTION

Python, SQL and workers

ETL, matching, suppression, scoring, validation and CRM synchronisation.

05 · MEMORY

PostgreSQL + object store

Canonical records, audit logs, imports, documents and tenant isolation.

Division of responsibility

Give every layer the work it does best.

HERMES

Operations manager

  • Starts client-scoped runs
  • Calls workflows in sequence
  • Produces daily briefs
  • Maintains campaign state
  • Escalates exceptions
OBSIDIAN

Human operating memory

  • Client playbooks and voice
  • Campaign strategy
  • SOPs and call scripts
  • Meeting and learning notes
  • Human-readable reporting
CODE + SQL

Reliable machinery

  • Normalisation and dedupe
  • Address and identity matching
  • Consent and suppression
  • Frequency caps
  • Scoring and synchronisation
LOCAL MODEL

High-volume interpretation

  • Classify CRM notes
  • Extract intent and outcomes
  • Summarise histories
  • Categorise replies
  • Draft initial personalisation
FRONTIER API

Complex escalation

  • Campaign planning
  • Ambiguous cases
  • Long-context analysis
  • Workflow improvement
  • Automation debugging
HARD LIMIT

No unrestricted autonomy

Agents do not independently mass-send, erase records, decide consent, share tenant data or scrape arbitrary sources.

The five service engines

Turn databases and territory into appointment opportunities.

01

Database reactivation

Import past vendors, buyers, appraisals, open-home attendees, withdrawn listings, lost listings and neglected enquiries. Clean, classify and convert them into approved call and nurture queues.

02

Homeowner territory

Use properly licensed ownership and property data to identify long-held properties, absentee owners, portfolio owners, withdrawn listings and relevant life-cycle signals.

03

Buyer-demand matching

Match active buyer requirements against properties and known owners, creating a concrete reason for the agency to initiate a conversation.

04

Trigger and nurture

Move every lead through explicit states—from unknown and engaged through appraisal, likely seller, appointment, listing, nurture or suppression.

05

Principal intelligence

Deliver a daily brief containing top prospects, neglected opportunities, seller signals, buyer matches, unanswered replies and recommended actions.

COMPLIANCE GATE

No clearance, no contact

Every outbound action checks relationship, consent source, permitted channel, suppression status, Do Not Call status, client exclusions and frequency limits.

Operating efficiency

Do not spend model intelligence on database chores.

DETERMINISTIC FIRST

Code handles certainty

Phone formatting, date parsing, address matching, deduplication, territory filters, suppression, arithmetic scores and record validation should be ordinary software.

MODEL ROUTING

Escalate only when needed

Run repetitive language work on a local 14B–32B model. Send only difficult, ambiguous or strategically important work to the frontier model.

SHARED CONTROL PLANE

Queue twenty clients

Use one orchestrator, tenant-scoped credentials, isolated schemas, stateless workers and a central queue instead of twenty continuously running agents.

EXPECTED EFFECT

Cut frontier usage dramatically

Correct routing can avoid sending 80–95% of routine records to the expensive model while improving reproducibility and auditability.

Offline operating mode

Local processing—not an air gap.

The system can keep sensitive transformation and classification local, but production prospecting still requires controlled connections for licensed data, CRM sync, suppression washing, email, SMS, calls and reporting.

1

Ingest narrowly

Pull approved data into encrypted staging through source-specific connectors.

2

Process locally

Normalise, classify, match and score without exposing the full dataset to remote models.

3

Approve queues

Produce a contact queue that passes compliance rules and human review.

4

Reconnect narrowly

Send only approved actions through audited channel-specific integrations.

5

Record everything

Write activity, evidence, outcomes and suppression events into the audit trail.

6

Retain deliberately

Purge temporary data and exports according to documented retention policy.

Machine recommendation

Buy a worker, not a datacentre.

One capable workstation can support twenty clients because the workload is queued, most transformations are deterministic, and language-model jobs can run in batches.

BEST CASHFLOW OPTION

Used RTX 3090 workstation

  • Ryzen 9, high-core Intel or used Threadripper
  • RTX 3090 with 24 GB VRAM
  • 128 GB system RAM
  • 4 TB internal NVMe
  • 8–16 TB encrypted backup
  • Quality 1000–1200 W PSU and UPS
  • Ubuntu Server, PostgreSQL, Ollama/llama.cpp/vLLM

Indicative build target: AUD $3,500–$5,500.

QUIET MAC OPTION

High-memory Mac Studio

  • Prefer 96 GB or more unified memory
  • Excellent energy efficiency and acoustics
  • Convenient local inference and Mac workflow
  • Limited upgrades and no CUDA
  • Higher configured purchase price

Choose this when simplicity, noise and power use matter more than maximum stack flexibility.

Do not build around self-hosting a frontier-scale GLM model. A model in the hundreds of billions of parameters requires hundreds of gigabytes of high-bandwidth memory before context and runtime overhead. At this stage, API escalation is overwhelmingly more economical.

Twenty-client economics

Compute is not the expensive part.

Monthly infrastructure itemLow caseHigh case
Frontier model APIAUD $200AUD $500
Server amortisationAUD $100AUD $180
ElectricityAUD $30AUD $100
Backups and storageAUD $30AUD $100
Monitoring / gatewayAUD $10AUD $50
Estimated compute infrastructureAUD $370AUD $930
ILLUSTRATIVE LOAD

60,000+ records touched monthly

Twenty clients with 5,000 historical contacts each, 2,000 refreshed property prospects each month and 1,000 active analysed contacts each can be handled comfortably by PostgreSQL and queued workers.

TRUE COST CENTRES

Data and execution dominate

Licensed property data, contact enrichment, telephony, SMS, email infrastructure, compliance, onboarding, CRM integration and human appointment-setting will cost more than inference.

Canonical data model

Separate people, property, relationships and permission.

clients properties people property_ownership contact_points client_relationships consent_evidence suppression_records campaigns campaign_members activities conversations lead_scores buyer_requirements property_matches tasks appointments agent_decisions data_sources import_batches audit_events
The critical modelling rule

A person may own multiple properties; a property may have multiple owners; and the same person may be known to multiple agencies. Each agency relationship, permission and suppression status remains separately controlled.

DB

Implementation sequence

Prove appointments before building SaaS.

PHASE 1

Database reactivation with three agencies

Build import, cleaning, note classification, scoring, approved call lists, outcome capture and weekly ROI reporting.

PHASE 2

Add territory prospecting

Integrate licensed property data, territory segmentation, buyer matching, suppression controls, letters and compliant call queues.

PHASE 3

Harden the multi-client control plane

Add tenant isolation, secret management, queueing, dashboards, billing metrics, onboarding, monitoring and full audit history.

PHASE 4

Extract the SaaS product

Productise stable ingestion, lead states, compliance rules, orchestration, opportunity dashboards and attribution reporting.

Recommended build

Local workers.
Frontier escalation.

Hermes orchestration + PostgreSQL canonical database + Obsidian control room + a 14B–32B local model + API escalation + licensed data connectors.

One shared control planeStrict tenant isolationHuman-approved outreachDeterministic compliance gatesAUD $4k–$6k hardware ceiling
Return to strategy