Voice AI & Telephony

An Orchestrated Deterministic-and-Agentic Operations Layer for a UK Property Developer

How Pfactorial Technologies designed an AI agent system that automates document filing, planning-condition chasing, supplier pricing, and errand tasks for a UK property developer, splitting each workflow between deterministic code and agentic judgement.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_UK_Property_AI_Agent image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client, a UK property developer operating six developments, was running planning administration, supplier pricing, document filing and a long list of other operational processes largely by hand across email, spreadsheets and phone calls, and wanted an operator that could plan its own steps and work unattended for hours - not a chatbot.

A single general-purpose agent handling everything would not have solved this: its context would fill with irrelevant material and its tools could be misused by the wrong task, and several of the developer's own workflows - planning portal form-filling, live spreadsheet edits - are exactly the kind of well-defined, high-risk steps that should never be left to a model's judgement in the first place.

Pfactorial designed a hybrid orchestration layer: one orchestrator owning job state, approvals and retries, with deterministic code handling known steps and specialised agentic workers handling judgement calls, drawing directly on production patterns already proven in Pfactorial's own HMO AI Agent, Real Estate Voice Agent and TaxPilot systems.

Why this engagement is representative This engagement demonstrates Pfactorial's ability to take a long list of 'automate this' requests and correctly split each one between deterministic code and agentic reasoning - the discipline that keeps an operations layer dependable rather than a demo that fails the first time a step breaks.

THE CHALLENGE

Turning a property developer's list of manual workflows into an operations layer meant solving problems that don't show up until a step runs unattended and something goes wrong.

1. Not every task on the list should be an agent

Portal form-filling and live spreadsheet edits are well-defined, repeatable steps that need idempotency and an audit trail, not a model's interpretation applied fresh each run.

2. Document filing spans six developments with no single naming convention

Files arriving by email have to be classified, prefixed and routed without a developer team, with low-confidence cases going to review rather than a guessed folder.

3. Planning conditions run on a ten-week chase cycle held in state for months

The notice has to be read, conditions extracted, and the chase held open across weeks without a person keeping track by hand.

4. A failed step needs a boundary, not a loop or a silent stall

A tenant who doesn't reply, a supplier who never responds, or a portal submission that half-completes all need a designed point where the system stops trying and tells a person why.

The real brief Not "build an agent for everything on the list" but "combine deterministic workflows with agentic judgement so the system is predictable where the steps are known and adaptable where they aren't - and give every unattended path a defined point where it hands back to a person."

THE SOLUTION

Pfactorial designed the operations layer around one orchestrator owning job state, approvals and retries, with specialised workers underneath for documents, planning, portal automation, research and voice - not one general agent trying to do all of it.

Pfactorial_Case_Study_UK_Property_AI_Agent image 2

Figure 1 - Deterministic workers handle known steps identically every time; agentic workers apply judgement where interpretation is needed - both held in state by one orchestrator.

Architectural principles

Deterministic where the steps are known, agentic where judgement is needed - Well-defined triggers and outcomes run through code; models are introduced only where interpretation, reasoning or conversation adds real value.
One orchestrator, specialised workers - not one general agent - A single agent's context fills with irrelevant material and its tools can be misused by the wrong task; separating job state and approvals from execution keeps each worker narrow and auditable.
Models sit behind an internal interface - Routing a reasoning model versus a smaller classification model is a configuration choice, not a rebuild - already proven in production, where the reference systems run GPT-5 and Claude Sonnet on different workloads and route across three providers.
Every unattended path has a defined boundary - Retries, a channel switch, then human handoff at a fixed point - an agent without that boundary either loops or gives up silently.

CAPABILITIES DELIVERED

Each item on the developer's list was mapped individually to how it should actually be built, not automated uniformly.

CAPABILITY	WHAT IT DOES
Document filing across six developments	A deterministic pipeline with model-assisted classification and naming; low-confidence cases route to a review queue instead of a guessed folder.
Planning condition management	Agentic: the notice is read, conditions extracted, and a ten-week chase cycle held in state for months.
Planning portal form filling	Deterministic browser automation for ten known steps that run identically every time, with idempotency and a screenshot trail.
Quarterly supplier pricing round	Sending and gathering are deterministic; matching a merchant description to the developer's own product is a model task, accurate because it's trained on a year of historic price lists.
Competitor market watch	Scheduled collection with agentic comparison, surfacing the monthly delta against the developer's own pricing as the output worth reading.
Scheduled edits to live spreadsheets	Deterministic, with guards: a dry run, a written diff and a backup before any cell changes, the riskiest item on the list.
Errand tasks & document retrieval	Agentic open-ended research and retrieval over a deterministic index, since a file pulled off a portal is rarely named for what it contains.

Pfactorial_Case_Study_UK_Property_AI_Agent image 3

Figure 2 - The same deterministic-plus-agentic split, and the same escalation boundary, applies whether the task is filing an email or chasing a planning condition.

Design note The riskiest item on the list - scheduled edits to live spreadsheets - was deliberately kept deterministic rather than agentic, with a dry run, a written diff and a backup required before any cell changes; the temptation to let a model 'just handle it' was traded for predictability on the one workflow where a wrong guess is expensive to unwind.

ENGINEERING FOR SCALE AND RELIABILITY

Five decisions carried over from Pfactorial's proven reference systems into the design for this engagement.

An orchestrator owning job state, not workers tracking their own state

Centralising job state, approvals and retries in one place is what makes a stalled multi-week workflow - like a ten-week planning condition chase - resumable rather than lost.

Browser automation treated as deterministic, not agentic, when the steps are known

The planning portal has ten known steps that should run identically every time; that calls for idempotency and a screenshot trail, not a model reasoning through a form afresh on every run.

Escalation boundaries designed before the happy path

The reference HMO agent's failure behaviour - retry, channel switch, then human handoff at a fixed point - was designed first, because an agent without that boundary either loops or gives up silently.

Third-party integrations isolated behind webhooks

Make.com webhooks decouple core orchestration logic from any single third-party API's misbehaviour, so an integration failure doesn't propagate into the orchestrator's state.

Models behind an internal interface, swappable per workload

Routing GPT-5 for reasoning and a smaller model for classification is a configuration choice rather than a rebuild, already proven across the HMO agent and TaxPilot's three-provider routing.

DELIVERY APPROACH

The engagement builds outward from the proven reference architecture, mapping the developer's own workflow list onto it item by item.

1. Reference architecture review - walking the developer's own workflow list against the HMO Agent, Real Estate Voice Agent and TaxPilot as proven patterns for orchestration, state and retrieval.

2. Deterministic-versus-agentic mapping - classifying each of the ten workflows on the list - filing, planning conditions, portal automation, supplier pricing, competitor watch, spreadsheet edits, errands, retrieval, blog drafting - by how well-defined its steps are.

3. Orchestrator & state design - designing the job-state, approval and retry model that lets multi-week processes like planning-condition chases survive across runs.

4. Deterministic workers - building portal automation, document filing and guarded spreadsheet-edit pipelines with dry runs, diffs and backups.

5. Agentic workers & escalation boundaries - building condition extraction, supplier matching and research workers, each with a designed retry-then-handoff boundary.

RESULTS AND IMPACT

Pfactorial_Case_Study_UK_Property_AI_Agent image 4

- Key outcomes from this engagement.

The design work produced a workflow-by-workflow build plan for the developer's operations - document filing across six developments, planning-condition chasing, portal form-filling, supplier pricing, competitor watch, guarded spreadsheet edits, errand tasks, document retrieval and blog drafting - with each item assigned to deterministic code or an agentic worker based on how well-defined its steps actually are.

Because the architecture reuses an orchestrator pattern, an escalation boundary, and a swappable model interface already proven across three production systems, the developer gets a dependable operating layer rather than a set of workflows that only work in a demo.

What it enabled commercially

The developer gets an operations layer scoped to exactly the workflows it runs today - six developments' worth of filing, a multi-week planning-condition chase, portal submissions and supplier pricing - built on patterns already proven in production, so scope can grow without redesigning the orchestration underneath it.

WHY PFACTORIAL

This engagement sits within Pfactorial's applied agentic-systems practice: combining deterministic workflows with agentic reasoning behind one orchestrator, a discipline proven across the HMO Agent, Real Estate Voice Agent and TaxPilot before it was ever applied to a new client's own workflow list.

Pfactorial_Case_Study_UK_Property_AI_Agent image 5

- Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with property developers and operations-heavy businesses that want unattended workflows they can trust, not a chatbot with a demo happy path. If you're evaluating an agentic operations layer, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.