A material study photographed in bright daylight. A tall radial fan of clear turquoise glass fins opens like a wheel on the right of the frame, a polished pearl silver ribbon curving down out of its centre and along a pale reflective floor. The left of the frame is empty pale mint.
  1. Home
  2. Services
  3. Agentic operating systems

One of the eight services

Agenticoperating systems.

An agentic operating system is a layer over the software you already run. Agents are given a goal, work inside your tools, and stop at the decisions you reserve.

The output is not an answer. It is finished work, and a record of how it got finished.

Book a discovery call Request a performance audit

Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit.

HUREAL / Material studies

Block 02

Soundslike this?

  1. Requests arrive after we close, and they sit until somebody opens the inbox in the morning.

  2. We just hired a coordinator to keep up with the volume, or we are about to.

  3. A spreadsheet is what connects two systems that do not talk to each other.

  4. The Monday report takes most of Monday.

  5. Every quote we send needs somebody to remember to chase it.

  6. The same six questions come in every day, and each one still needs a person to answer it.

  7. In the busy season we cover the extra volume with overtime.

If none of those is familiar, the thing you are looking for is more likely a connection between two systems than an agent working inside them, and Integrations and Data is the page for that.

Block 03

What this is,in plain language.

What happens today

An inquiry arrives at eleven at night. It waits in an inbox. In the morning somebody reads it, works out whose it is, types the details into the customer record, checks the price list, writes a reply, and makes a note to chase it on Friday.

Most of that is reading, re-keying, looking up and chasing. None of it is the decision. The decision is one sentence in the middle, and it is the only part that needed a person.

What happens after

The same inquiry arrives at eleven at night. It is read, checked against your own documents, recorded in your CRM with a source and an owner, qualified against the rules you wrote, and drafted in your format and your terms.

Then it stops, because sending it is a decision. In the morning one person opens one queue, reads what is waiting, and releases what should go. The chasing afterwards is not theirs either.

An assistant answers the question. An agent finishes the job.

It books the meeting, updates the record, sends the confirmation, and tells you it is done. We call it an operating system rather than an app because it is a layer: it sits on top of the CRM, the accounting package, the inbox and the industry system you already run, and connects them, so the business gets work finished instead of coordinated. Your tools stay. Your data stays yours.

Four guardrails are engineered in from the first design rather than added later: defined limits per agent, approval gates on anything sensitive, answers grounded in your own documents with the source shown, and a full log of everything the system did and why.

Block 04

Who this is for,and who it is not for.

Where this pays for itself

  • Roughly 20 to 500 people, where a process costs real money and the person who can change it is reachable inside a week.
  • Work arrives outside office hours and waits for the office to open.
  • Two systems are bridged by a person and a spreadsheet, and everybody knows which spreadsheet.
  • Volume is seasonal and the peak is covered with overtime rather than with headcount.
  • Something is written down: a price list, a policy, a set of documents an answer could be grounded in.
  • Somebody senior can say what the system may never do without convening a committee to decide it.

You probably do not need this if

  • The process runs a few times a week and one person holds it comfortably. An agent is overhead at that volume, and we will say so on the discovery call.
  • The work is one rule with no judgement in it. That is automation. It costs less than anything we would build, it will not drift, and it is usually configured rather than made.
  • Nothing is written down yet. Grounding needs documents. Where the price list lives in one person's head, the first useful project is writing it down, and that is a different job.
  • The requirement is "we should have some AI". There is no workflow in that sentence to scope, and a scope is what phase one exists to produce.
  • The requirement is that nobody reviews anything. Every system we build has a gate in it. If the gate is the part that needs removing, we are not the right builder for it.

Where the answer is the smaller thing, we will say so, and we will build the smaller thing.

Block 05

What itincludes.

Fifteen capabilities, what each one does in plain words, and what it changes for the business. Nothing here is a category name standing in for work.

Agentic operating systems, the capability table
Capability What it does What it changes
Design the boundaryBefore any code
Workflow selection The process that costs the most, mapped end to end with the people who actually run it. You find out what it is worth before you pay to build it.
The line, written down What the system takes over and what stays with your people, agreed and signed before the build starts. Nobody discovers the boundary after launch.
Agent design Role, tools, limits, escalation rules, and the list of things each agent may never do. The system's authority is a document, not a setting somebody remembers changing.
Approval gates Which actions wait for a person, and the queue that person actually works in. Sensitive work does not go out because a model sounded confident.
Build the systemThe first workflow, end to end
Grounding Your documents, policies, price lists and history connected, with the source shown in every answer. An answer you can check against the page it came from.
Integrations The CRM, email, calendar, accounting, e-commerce, phone and industry systems you already run. The work is finished where your records already live.
Multi-agent handoffs A process that crosses departments, with the handoff and the owner defined at each step. Work does not stall at the border between two teams.
Memory Context that survives between conversations and across weeks. The customer does not start again every time they get in touch.
Per-language operation Customer-facing work authored per language rather than translated after the fact, including the automated replies and the error states. Your customers read something a person would have written.
The audit trail A record of what the system did and why, written for a person rather than for an engineer. A mistake is findable instead of mysterious.
Run itAfter launch
Shadow running The system does the work alongside your people, who see everything and approve everything, until the output is trusted. The wrong answers happen where they cost nothing.
Monitoring Drift and performance watched after launch, with alerts pointing at a named person. You hear about a change from us rather than from a customer.
Data handling documentation What the system holds, where it holds it, and for how long, prepared for your privacy officer. Your privacy officer has something to read on the day they ask for it.
Inside the product itself Sub-service
Search that understands intent People find the thing they meant rather than the words they happened to type. Fewer calls that start with "I could not find it on the site".
Documents that read themselves Inbound documents parsed into the fields your systems expect, with the low-confidence ones handed to a person. The re-keying stops at the door instead of after it.

Scroll the table sideways to read it.

The smallest version of this

Three fixed-scope modules, sold inside a build rather than on their own.

A full operating system is not the only way in. Three modules have a fixed scope, which means their price is a commitment written into the signed scope of the build: if delivery runs over, HUREAL absorbs it. They are modules of a build, not a subscription, and they sit under this service rather than beside it because that is what they are.

  • Follow-Up Fixed scope

    Quotes and inquiries chased on a schedule you set, twice, and then it stops. Every touch logged against the record.

  • Front Desk Fixed scope

    Inbound read, understood, recorded and routed to the right person, in the hours you choose, with everything sensitive held at the gate.

  • Site Answer Included with every build

    Your site answering a real question from your own documents, with the source shown.

See the three modules Hear one working

Block 06

How itworks.

One inquiry, ten steps, and one of the ten is yours. The gate is the largest object in the drawing because it is the largest object in the promise.

Scroll the drawing sideways to read it.

Ten steps, one of them yours. The gate is the only dark plate on the board, and it is never used because a section needed weight.

What the system does

The work, the path it takes, and everything HUREAL builds. It never means anything else.

What stays with a person

The line, its single opening, and the plate standing in it. On a light board it is the one dark plate.

What you already run

Present, named, and not for sale. The lowest contrast on the board, deliberately.

  1. It arrives, and it is read.

    An email, a form, a call or a message. The system works out what is being asked, who is asking, and how urgent it is, in the language it was written in. Nothing has been decided yet and nothing has left the building.

  2. It is checked against what you know.

    Your price list, your policies, your documents and this customer's history. An answer the system cannot ground in one of those is not improvised: it is marked and handed to a person, and the handover is in the log.

  3. It becomes a record, then a draft.

    The record is created in your CRM with a source, an owner and the time it arrived. It is qualified against the rules you wrote, put in the right queue, and drafted in your format and your terms.

  4. It stops at the line.

    Everything the system produces waits at one line with one opening, and the plate standing in the opening is a person. You release it, or you do not. Nothing crosses because a model was confident, and nothing crosses on a timer.

  5. What you release is sent, chased, and logged.

    It goes out in your voice, it is followed up twice and then it stops, and every step of it lands in a log you can read and in the monthly report. The record of the work is a deliverable, not a side effect.

The shortest version of that drawing is a few minutes in your browser. Paste your own address and hear it answer as your business. No form, no booking.

Hear it work

Block 07

What youend up with.

  • The workflow map

    The process that costs the most, drawn end to end, with the people who run it named against each step.

  • The written line

    What the system takes over and what stays with your people, in a document, signed before the build.

  • An agent brief per agent

    Role, tools, limits, escalation rules, and the list of things it may never do.

  • The approval queue

    The screen a person works in, showing everything that is waiting and why it is waiting.

  • The grounded knowledge set

    Your documents, policies and price lists connected, with the source shown in every answer.

  • The audit trail

    Every action and its reason, in plain language, exportable, kept whether or not anything went out.

  • The controls

    Limits you can tighten yourself, and an off switch that works without calling us. Both tested before launch day.

  • The data handling document

    What is held, where, by which processor, and for how long. Written for your privacy officer.

  • The accounts

    The system, its configuration and its data in your own cloud accounts, under your admin access, from the first commit.

V3. The audit trail, drawn

your-company/agent/log Thursday, 6 entries

What it did, and why

Written for a person. Exportable. Kept whether or not anything went out.

  • 09:12

    Read an inquiry from a returning customer and matched it to their account.

    Grounded in the account record and the last three orders.

  • 09:12

    Created the record in your CRM with the source, the owner and the time it arrived.

  • 09:13

    Drafted a reply quoting list price for two of the three items, and stopped.

    Held the third item is priced by exception, which is on your side of the line.

  • 09:41

    Released by your operations lead. Sent.

  • 13:20

    No reply yet. Followed up once.

    Rule twice, and then it stops.

  • 16:05

    Handed a second inquiry to a person without answering it.

    Not grounded nothing in your documents answers a question about a delivery date for that item.

Two of the six entries are the system declining to act. That is the design working rather than the design failing, and it is the reason the log is a deliverable instead of a debug file.

On every HUREAL engagement, whichever of the eight it is

  1. A written scope with a fixed price and a timeline, before any code.
  2. The working build, reviewed at every phase, in your own accounts.
  3. Full ownership of the code, the content and the data, with admin access from day one.
  4. A named contact who is accountable for the work.

Block 08

How anengagement runs.

Five phases. You can stop after any of them, and every one produces a document you own.

  1. 01

    Discovery call

    A discovery call with the people who own the outcome. We map the workflow that costs the most, agree what the system takes over first and what stays with your people, and list the systems involved.

    How long
    One call. The written proposal follows it.
    Your people
    Whoever owns the process.
    You end up with
    A written proposal: a scope, a price and a timeline you can sign or walk away from. Yours either way.
  2. 02

    Design

    The guardrails, before code. Limits per agent, approval gates, escalation rules and the logging model, agreed and written down while they are still cheap to change.

    How long
    Set in the signed proposal.
    Your people
    Whoever can say what the system may never do.
    You end up with
    The line, drawn, and an agent brief for every agent in the first workflow.
  3. 03

    Build

    One workflow, end to end, demonstrated on your real cases rather than on samples. It runs in your own cloud accounts, under your admin access, from the first commit.

    How long
    Set in the signed proposal, with the review schedule agreed in it.
    Your people
    One reviewer per review, plus whoever owns the systems being connected.
    You end up with
    Working software at every review, in your accounts from the first one.
  4. 04

    Launch

    Shadow running first: the system does the work alongside your people, who see everything and approve everything, until the output is trusted. Then the same fourteen published checks every HUREAL build passes.

    How long
    A shadow run of the length agreed in the proposal, then the checklist against the finished build.
    Your people
    The team that will work the queue, plus an admin sign-in before launch day.
    You end up with
    A launch record against fourteen named checks, and the gates set where you set them.
  5. 05

    Run

    Monitoring for drift, tuning, and the next workflow when you want it. The gates loosen only where you decide, and never by default. Monthly, and cancellable.

    How long
    Monthly, for as long as you want it. Cancellable at any time.
    Your people
    One read of the monthly report and one call to pick what changes next.
    You end up with
    A written report: what the system did, what changed, what it produced, and what did not work.

What makes it longer: how many systems it connects to, how much of your knowledge is already written down, how many departments the process crosses, and how long you want it shadow running before the gates are reviewed. What does not make it longer: how many agents you eventually want. The second workflow is faster than the first every time, because the guardrails, the grounding and the queue are already built.

Read the whole method, including the fourteen launch checks

Block 09

What itconnects to.

By category, because the category is the question. The first real objection is whether this works with what you already run, and the honest answer is a list plus a qualifier, not a wall of logos.

  • CRM

    Where the record is created, and where the source and the owner live.

    Salesforce, HubSpot, Zoho, Dynamics

  • Accounting and ERP

    Where price, stock, credit and invoices are true.

    QuickBooks, Sage, NetSuite, SAP

  • Email, calendar and messaging

    Where the inquiry arrives and where the reply goes back.

    Microsoft 365, Google Workspace, WhatsApp Business

  • Booking and scheduling

    Where a slot is held, moved or released.

    Calendly, Acuity, an in-house dispatch board

  • Phone and voice

    Where a call is answered, transcribed, and turned into a record.

    RingCentral, Twilio, your existing phone system

  • E-commerce

    Where an order, a return or an account price already exists.

    Shopify, WooCommerce, BigCommerce

  • Documents and storage

    Where the policies, price lists and history the answers are grounded in actually live.

    SharePoint, Google Drive, Dropbox

  • Your industry system

    The one system that runs your trade, which is usually the one that matters most and the one nobody else connects to.

    dispatch, estimating, practice management, property management

  • Your own database

    Where a system has no interface to connect to, the connection is built rather than assumed.

    read-only views, scheduled exports, a purpose-built interface

Every connection is validated by HUREAL's engineers during scoping and confirmed in writing before signature. Where a system genuinely cannot be connected, you hear it during discovery rather than during the build, and the scope is drawn around it instead of making a platform migration the price of entry.

Block 10

The line,drawn before you sign.

What the system takes over

  • Reading what arrivesEmail, form, call and message, in the language it was written in.
  • Grounding the answerChecked against your own documents rather than against the internet, with the source shown.
  • Recording itCreated in your CRM with a source, an owner and the time it arrived.
  • Qualifying and routingAgainst the rules you wrote, not against a guess about what you meant.
  • DraftingYour format, your terms, your price list.
  • Following upTwice, and then it stops.
  • ReportingWhat it did, what it held, and what it handed over.

What stays with your people

  • PriceAnything outside the published list is a person's decision, every time.
  • Credit and termsWho gets them, and on what basis.
  • ExceptionsThe customer who is not like the others, and the job that is not like the others.
  • RelationshipsThe call that matters is made by the person whose name is on it.
  • The final wordNothing that carries your name goes out until somebody released it.
  • The limits themselvesYou tighten them. You do not ask us to.
  • The off switchIt works without calling us, and it is tested before launch day.

That boundary is a document before it is a setting. It is agreed in phase one, written into the build in phase two, and visible in the audit trail afterwards. So the question is never what the system is allowed to do. It is where to read what the system is allowed to do, and the answer is: the same page you signed.

Block 11

Automation, an assistant,or an agent.

Three different things are sold under one word. They cost different amounts, they fail differently, and two of the three are often the right answer.

The three approaches, on eight deciding factors
Deciding factor A rule-based automationConfigured An assistant in a windowLicensed An agent that finishes the jobBuilt
What it produces A step that fires when a condition is met. An answer, for whoever asked. Completed work, and a record of how it got completed.
Who works out the steps You do, in advance, for every case you thought of. The person reading the answer. The system, inside limits you wrote down.
A case nobody predicted Nothing fires, and often nobody notices. It answers anyway, and sounds just as sure. It stops, hands over, and the handover is in the log.
Where the work ends up In the tool the rule lives in. On the screen of whoever asked. In the systems you already run.
What it knows Whatever is in the trigger. What it was trained on, plus whatever was pasted in. Your documents, your price list and your history, with the source shown.
Cost to change it later Low. One rule at a time. Nothing to change. Higher, because a change is designed, tested and logged.
Cost to start Lowest. Usually configured rather than made. Low. Usually a licence you may already hold. Highest. It is a build.
When it is the right answer The process is one rule, and the rule is stable. People need to ask questions and act on the answers themselves. The work has judgement in it, crosses systems, and currently waits for a person.

The verdict, including where it goes against us

If the process is one rule and the rule is stable, buy the automation. It costs less than anything we would build, it will not drift, and a rule that has run for three years without an exception does not need a system that reasons about it.

If what your people mainly need is to ask questions, an assistant is enough, and most of the software you already own now includes one. Paying for a build to get that is paying twice.

Agents earn their cost in one place, and it is a narrow one: work that has judgement in it, crosses more than one system, and currently waits in a queue until somebody gets to it. That is the whole case, and the discovery call is where we find out whether your process is in it.

Block 12

What a Canadian buildhas to be designed around.

A system that reads customer messages and acts on them touches more law than a website does. These are the requirements this service is designed around, and the line between what we build and what your counsel decides.

  • PrivacyPIPEDA, and Quebec's Law 25 where it applies

    What we design forA stated purpose for every system an agent can read, the smallest tool list that does the job, consent captured where the agent initiates contact, and retention set per record type rather than left at a default.

    What we document for your counselWhat the system holds, where it is stored, who can reach it, how long it is kept, and every place a decision about a person is made with automated assistance.

  • Health informationWhere the work touches it at all

    What we design forNo health information in an agent's context until the storage region and the handling are settled. Where they are not settled, the workflow is scoped to exclude it rather than scoped around it.

    What we document for your counselWhich data classes were excluded and why, so the boundary is something your privacy officer reads rather than infers.

  • Electronic messagesCASL, for anything automated

    What we design forConsent and its basis recorded against the record before any automated follow-up, an unsubscribe that works in one action, and a follow-up sequence that stops rather than loops.

    What we document for your counselThe consent basis per contact and the full send log, which is the evidence the legislation asks you to be able to produce.

  • AccessibilityWCAG 2.2 AA, plus AODA or the Accessible Canada Act where they apply

    What we design forEvery surface a person actually uses, which on this service means the approval queue, the audit trail and any customer-facing reply. Keyboard, screen reader, contrast and reduced motion, tested rather than asserted.

    What we document for your counselThe test results per surface and the standard tested against, so a barrier report can be answered with a measurement.

  • LanguageQuebec's Charter of the French Language, where the business operates there

    What we design forPer-language operation as a first design decision rather than a translation pass at the end. Customer-facing text is authored per language, including the automated replies, the error states and the follow-up.

    What we document for your counselWhich surfaces are authored per language and which are not yet, so the gap is a list somebody owns rather than a surprise.

  • Where the data livesAnd which processor sees it

    What we design forThe storage region and the model region named in the scope before the build, chosen rather than inherited from whatever a vendor defaults to.

    What we document for your counselEach processor, what it sees, the region it sees it in, and what changes if you move region later.

HUREAL designs to a standard, tests against it, and documents what was built. The determination is your counsel's or your privacy officer's to make, and a vendor offering to make it for them is offering something they do not have. Our own conformance target and how to report a barrier are on the accessibility page.

Block 13

Questions peopleactually ask.

  • What happens when it gets something wrong?

    The design assumes it will. Sensitive actions wait for a person, anything the system cannot ground in your documents is handed over rather than guessed at, and every action is logged so a mistake is findable. The first workflow runs in shadow mode alongside your team precisely so the wrong answers happen where they cost nothing.

  • Are you replacing our staff?

    No, and we will not scope a project on that basis. What the system takes over is the reading, routing, chasing, drafting, re-keying and reporting. Price, credit, judgement and relationships stay with your people, and the block above this one lists exactly which is which, before you sign anything.

  • Do we have to change our software?

    No. The system works inside what you already own, and the categories it connects to are listed above. If a tool genuinely cannot be connected, you hear it during discovery and the scope is drawn around it rather than making a platform migration the price of entry.

  • Who owns the system, the configuration and the data?

    You do. The build runs in your own cloud accounts under your admin access from the first commit, so there is nothing to hand over at the end. Developer and platform accounts are opened in your name, and we do not hold your passwords.

  • Is our data used to train a model?

    No, and that commitment sits in the contract rather than only on this page. The storage region and the model region are named in the scope before the build, chosen rather than inherited from a default, and each processor and what it sees is documented for your privacy officer.

  • What does it cost?

    The build price is set after the discovery call and sent in a written proposal, because an honest number needs the scope. Fixed scope, fixed price, fixed timeline, agreed before any code. Not hourly, and not a range that moves once work starts.

  • How do we check that you can actually do this?

    Four ways, all of them before you sign anything. The method is published phase by phase. The fourteen launch checks are published by name. The demonstration answers you in the browser right now. And phase one produces a written scope, price and timeline that is yours whether or not you continue.

  • How long before the first workflow is doing real work?

    Set by the signed scope, and the shape of it is published above rather than promised as a number here. What makes it longer: how many systems it touches, how much of your knowledge is already written down, and how long you want it shadow running. What makes it shorter is the second workflow.

  • How is this different from the automation we already have?

    An automation fires a step when a condition somebody predicted is met. An agent is given a goal, works out the steps, uses your tools, checks your documents, and asks a person when something is unclear or sensitive. If your process is one stable rule, the automation is the better answer and we will say so.

  • What if a tool we use cannot be connected?

    You hear it during discovery, before signature, rather than during the build. The scope is drawn around it, and the first workflow is chosen so the missing connection does not sit in the middle of it. Every connection is validated by our engineers during scoping and confirmed in writing.

  • Who is accountable when it runs unattended?

    A named person, and the run arrangement says who. Monitoring for drift and for performance runs after launch with alerts pointing at a person rather than at a shared inbox. The limits are yours to tighten without asking us, and the off switch is tested before launch rather than configured and assumed.

  • What if we want it to stop?

    You stop it. The off switch works without calling us and it is tested before launch day. The run arrangement is monthly and cancellable, and the system, its configuration and its data stay in your own accounts and keep running either way.

Block 14

Three servicesnext to this one.

Block 15

Where thismatters most.

Four sectors, and the reason in each

  • Construction and trades

    The quote goes out and then it needs somebody to remember it. Chasing is the single most expensive thing a busy trades office forgets to do, and it is the smallest thing an agent can take over first.

  • Manufacturing and distribution

    Order status, stock and account pricing are three systems and one phone call. The call is the part an agent removes, and the account price is the part that stays behind the gate.

  • Professional services

    Intake is a person reading an email and deciding whose it is. That decision has rules, the rules are usually already written down, and the conflict check that follows it is exactly the kind of work that should stop and wait.

  • Healthcare and clinics

    Named here with a limit rather than a pitch. HUREAL does not yet put a voice agent in a clinic: the Canadian-region infrastructure and the health-information posture that would need are not settled. Back-office work that touches no health information is a different question, and we will scope that one.

Read on this topic

Every article about this service lives under one index, so a reader who wants depth has one place to go rather than a tag cloud.

The agentic operating systems index

Everything we have published on this

Block 16

Two ways to start.Both end with a document you own.

Book a discovery call

For when you know which process is costing you. A discovery call with the people who own the outcome. We map the workflow, agree what the system takes over first and what stays with your people, list the systems involved, and work out what it pays back. Afterwards you get a written proposal: a scope, a price and a timeline you can sign or walk away from.

Book a discovery call

Request a performance audit

For when you want the evidence before the decision. We look at what you have against the job you want it to do, and give you a prioritised plan with the arithmetic attached. The document is yours either way.

Request a performance audit

Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit. If neither is right for you, we will say so, and tell you what is.

Not ready for either? Paste your own address in the demonstration and hear it answer as your business. No form and no booking.

Hear it work

What every HUREAL engagement commits to, in writing

  • A fixed scope, price and timeline, agreed before any code is written.
  • A working build, reviewed at every phase, running in your own accounts.
  • Full ownership of the code, the content and the data, with admin access from day one.
  • A named contact who is accountable for the work.
A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

Work that finishes, inside limits you set.

HUREAL / Material studies