Case study · Building consulting

An AI agent that turns enquiries into properly-filed jobs.

Every new job at United Building Consultants went through the Managing Director before it could start. We built an AI agent that runs the intake conversation, allocates the job number, sets up the SharePoint folder tree, and drafts the fee letter for review. It sits inside UnitedBC\'s own AWS account. Nothing writes until the MD confirms.

Talk to Tom about a similar build

At a glance

Client

United Building Consultants (UnitedBC)

Location

Melbourne, Australia

Industry

Building consulting (owners corp, building surveying, dispute reports)

Size

Owner-led small consultancy, growth-stage

Delivery window

August to September 2026 (Phase 1)

Delivery model

Build plus monthly subscription

The challenge

One person, every job, no exceptions.

UnitedBC is a Melbourne building consulting firm. Small team, owner led, technical work done properly, and enough enquiries coming in that the phone rarely stopped. The problem was not finding work. It was that every job funnelled through the Managing Director before anything could happen.

Every enquiry started as a conversation

New work came in by email, in Teams, over the phone. Each one needed a call on what kind of job it was, roughly what it was worth, and how it should be set up. Only the MD could answer those questions consistently.

Fee letters were reassembled every time

The process was: copy the closest old fee letter, edit the scope, tidy the formatting, save the PDF. Any inconsistency in scope or exclusions was a fight two years later when something went wrong on site.

Job numbers and folders held together by habit

The naming convention and job-number sequence stayed clean because the MD kept them clean. Adding a second person to the process was going to put that under pressure immediately.

The default fix was a hire

Second person on the desk, taking pressure off the MD. But that is a $90k+ committed cost, months before they are useful, and a management overhead the MD would rather not carry.

Why RYB

Built for how UnitedBC actually works.

There was no product to buy that would do this. The workflow touches Teams, email, SharePoint, Word templates, and naming conventions that have taken years to stabilise. A generic SaaS tool would have forced UnitedBC to change its process to suit the software.

We build agents for a living, and we do it end to end. Tom writes the production code, deploys into an AWS account UnitedBC owns, and integrates directly into the M365 tenant that is already there. There is no analyst layer in the middle, and we do not take vendor commissions on anything we recommend.

The commercial shape mattered at this size. Rather than a large project fee upfront, UnitedBC subscribes monthly. Everything already built stays live and keeps improving. Anything new gets quoted before it starts.

The architecture

How the system is built.

The whole thing runs on AWS in Sydney. Inference happens on Bedrock\'s AU profiles so no data leaves Australia. UnitedBC has its own account with its own IAM boundary. Every piece of the infrastructure is defined in CDK, so we can rebuild it or hand it over cleanly if we ever need to.

Inference and runtime

AWS Bedrock AgentCore (deployed on AU inference profiles in ap-southeast-2).
Anthropic Claude Haiku 4.5 and Sonnet 4.6 for reasoning.
Session-persistent agent that maintains context across a full job intake conversation.

Entry channels

Microsoft Teams bot (user-facing, delegated auth).
Email intake (agent reads job enquiries, replies with a proposal).
Web dashboard at unitedbc.redyellowblue.com.au for oversight and review.

Integrations

Microsoft Graph, cert-based app-only auth writing directly into the UnitedBC SharePoint tenant (not Power Automate, not a scraped layer).
FeeLetter MCP integration for fee-proposal document generation (Word and PDF).
DynamoDB atomic counter for job-number allocation (the number is never allocated by the model).

Infrastructure

Dedicated AWS sub-account, owned by UnitedBC, delivered under RYB Organization.
AWS CDK (infrastructure-as-code) for the entire deployment.
S3 for document artefacts, DynamoDB for state and audit trail, CloudWatch for observability.

What was built

What Phase 1 shipped.

From the MD\'s side it looks like one conversation with one assistant. Under the hood there are six pieces that had to be built and had to work together.

01 —
One agent, reachable in Teams or by email
the MD can start a job in email on Tuesday morning and pick it up in Teams that afternoon. The agent remembers the conversation across turns and channels, so nothing has to be re-explained.
02 —
Job numbers allocated by code, not by the model
When the MD confirms a job, a counter in DynamoDB hands out the next number. The model never picks it. The sequence cannot drift and a duplicate cannot happen.
03 —
Folder trees, four job types, right first time
Four job types are covered: owners corp, building surveying, dispute reports, and general consulting. Each has its own folder-tree template. Once the job is confirmed, the tree appears in the correct spot inside SharePoint straight away.
04 —
Fee letters drafted, MD sends
The agent drafts the fee letter against the right template. Word document and PDF, both dropped into the new job folder. The MD opens it, edits anything he wants to, then sends. The client only ever sees something the MD has reviewed.
05 —
Dashboard for oversight
A private dashboard at unitedbc.redyellowblue.com.au lists every job the agent has handled, every fee letter drafted, and every approval. If something looks off later, the trace is there.
06 —
Approve-first as the default
Anything that touches the real world (creating a job, writing to SharePoint, sending an email) is proposed and waits for the MD to confirm. Nothing writes automatically. That is how a small firm ends up trusting an agent inside 60 days.

Outcomes

What changed for the business.

Setting up a new job used to take the MD 20 to 30 minutes of clean-desk time. It is closer to 5 now.
Fee letters come off the correct template every time, without anyone having to remember to check.
The job-number sequence cannot skip or duplicate, and folders always land in the right spot.
UnitedBC has the whole thing in its own AWS account with source code, logs, and documentation. If something goes wrong, it is inspectable, not opaque.
Adding a new job type, or a second user, or reporting, is a small addition to what is already running. Not a new project.

Operating model

How the engagement is structured.

The build was one part of the engagement. The rest is a monthly subscription that keeps everything alive and moving forward on predictable terms.

Fixed-scope build, then subscribe

Phase 1 was a fixed-scope build. Everything since is monthly. The subscription covers AWS hosting, operations, and the small stream of template tweaks and config changes any live system needs. Anything genuinely new gets quoted before it starts.

The client owns the AWS account

UnitedBC owns the account and everything specific to its workflow. RYB keeps the underlying platform IP (FeeLetter, the agent patterns, the dashboard framework) because we use those across every client we work with.

A 30 minute steering call each month

What is working, what needs adjusting, and what to line up next. Teams is open between calls for anything urgent.

Clean exit if the arrangement ends

If the subscription ends, we run a 15 business day handover: open items, credentials, current-state documentation. The AWS account and everything in it stays with UnitedBC.

In the client\'s words

“Freeing up time away from admin means we can focus on what is important to our clients.”
Euan Morrison, Managing Director, United Building Consultants

If this shape looks familiar, let\'s talk.

If your firm has one person that every job goes through, this is the pattern we build around. Book 30 minutes and we will work out whether it fits.