- Home
- Services
- Agentic Operating Systems
- AI features in your product
Part of Agentic Operating Systems
AI featuresin your product.
An AI feature sits inside the thing a user came to do, so the task itself gets easier, rather than answering questions about it from a window off to the side. It is part of Agentic operating systems.
A feature that measurably changes how a task completes, with a scored evaluation set behind it.
Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit.
HUREAL / Material studies
In your words
Soundslike this?
People cannot find the product they meant in a catalogue we know has it.
Our staff answer the same questions from the same documents every day.
Invoices and purchase orders arrive and somebody retypes them.
Inquiries come in faster than anyone can qualify them.
Our forms ask customers for things we already know about them.
We added an assistant and it sits in a corner nobody clicks.
We would like to use AI, and nobody has named the task it would change.
If the work crosses systems and currently waits in a queue until somebody gets to it, that is an agent finishing a job rather than a feature inside one, and the page is Agentic operating systems.
In plain language
Inside the task,not beside it.
There is a version of AI in a product that answers questions in a window off to the side. There is another version that sits inside the thing the user came to do, so the task itself gets easier. The second is what we build.
Ask one question of any feature. Does this change what the user can get done?
Search that understands waterproof boots for a prairie winter changes what the user can get done. So does a form that stops asking for what it already knows, a photograph of an invoice that becomes a record, and an inquiry that arrives scored and routed. An assistant in a sidebar answering questions about the page does not.
These features depend on the business having usable information: documents, prices, policies, product data. We check that before we scope, because a feature with nothing to ground itself in is worse than none, and finding out after launch is the expensive way to learn it.
When the material is not there. Sometimes a narrow first feature is still possible and the work of organizing pays for itself anyway. Sometimes the honest first project is getting the data into one place, which is Integrations and Data. What we will not do is put an assistant on top of material that cannot support it and let you discover that after launch.
The capability table
What a featurebuild includes.
Thirteen capabilities, what each one does in plain words, and what it changes for the business. The last group is what separates a feature that survives its second year from one that quietly stops being trusted.
| Capability | What it does | What it changes |
|---|---|---|
| Before anything is builtThe feasibility question | ||
| Feasibility check | What information exists, in what state, and what it can support. | You find out what is possible before you pay for it. |
| Task selection | The action users perform most, where intelligence would change the outcome. | The feature has a job rather than a category. |
| The evaluation set | Real questions with what a good answer looks like, written down first. | Quality becomes a number rather than an impression. |
| The features themselvesInside the workflow | ||
| Search that understands intent | Over your catalogue, documents or listings, tuned per language. | People find the thing they meant. |
| Recommendations | Based on real behaviour, with rules you control. | The suggestion is relevant and it is still yours. |
| Document reading | Invoices, purchase orders, forms, identification and specifications, with the uncertain ones handed to a person. | The retyping stops at the door instead of after it. |
| Inquiry qualification and routing | Against your criteria rather than against a guess. | The bottleneck moves off the person who sorts. |
| Adaptive forms | Asking less, and pre filling what is already known. | Fewer abandoned forms, and less re-keying. |
| Assistants grounded in your approved material | With the source shown, and a handoff to a person. | An answer you can check against the page it came from. |
| How it stays honestAfter launch | ||
| Guardrails | What it may answer, what it must escalate, and what it may never say. | The failure case is designed rather than discovered. |
| Scoring before and after every change | Against the evaluation set rather than against a feeling. | A change that made it worse is visible before your customers find it. |
| Cost controls and reporting | These features carry a per use cost, and it is visible from the first month. | The running cost is a line you can read rather than a surprise. |
| Reporting on use, quality and escalation rate | And on the effect on the task itself. | The feature is judged on the job it was built for. |
Scroll the table sideways to read it.
How it works
The same line,inside one task.
The parent's drawing, read at the scale of a single feature. The steps across the top are what happens inside the task, and the gate is the same gate: whatever the feature is not allowed to decide on its own waits for a person.
Scroll the drawing sideways to read it.
Ten steps, one of them yours. A feature with no gate in it has not been designed, it has been switched on.
The work, the path it takes, and everything HUREAL builds. It never means anything else.
The line, its single opening, and the plate standing in it. On a light board it is the one dark plate.
Present, named, and not for sale. The lowest contrast on the board, deliberately.
-
It arrives inside the task.
A search, a form, an uploaded document or an inquiry. The difference from an assistant in a window is that nobody had to decide to use it: it is part of the thing they came to do.
-
It is checked against what you know.
Your catalogue, your documents, your prices and your policies. An answer the feature cannot ground in one of those is not improvised, it is marked and handed over, and the handover is in the log.
-
It becomes something usable.
A result, a filled field, a parsed record, a scored inquiry. The test is whether the next step got easier, which is why the evaluation set is written before the build rather than after it.
-
Low confidence stops at the line.
A document the reader is unsure about, a question outside scope, an answer with no source. Each one goes to a person with the reason attached rather than being answered anyway.
-
It is scored, and it is costed.
Against a set of real questions before launch and after every change, and against a per use cost reported monthly. A feature nobody scores is a feature nobody can defend in the second year.
An assistant with nothing to ground itself in is worse than none. The feasibility check happens before the scope, which is why the answer is sometimes that your first project is a different one.
The whole serviceThe deliverables
What youend up with.
- A feature that changes how a task completes
Measured against the task rather than against usage.
- A grounded knowledge source
Your approved material, updatable by your team without a developer.
- A scored evaluation set
Real questions with what a good answer looks like, so quality is a number.
- The guardrail document
What it may answer, what it must escalate, and what it may never say.
- Escalation paths
With a person at the end of them, designed rather than implied.
- Visible running costs
Estimated during scoping from your real volumes, and reported monthly.
- Reporting on use, quality and escalation rate
And on the effect on the task itself.
- The feasibility record
What material exists, what state it is in, and what it can support.
What is not on this list. Work that finishes on its own across several systems. That is an agent rather than a feature, and it is the parent: Agentic operating systems. The three fixed scope modules sold inside a build are on Agent modules.
By category
What a featureconnects to.
By category, because the category is the question. On this service the hardest connection is usually the last one on the list: your own application, which is where the feature actually has to live.
Product and catalogue data
Where the things people are searching for are described.
a product information system, an ERP, your own databaseDocument storage
Where the policies, price lists and specifications an answer is grounded in live.
SharePoint, Google Drive, DropboxCRM
Where a scored and routed inquiry becomes a record.
Salesforce, HubSpot, Zoho, DynamicsAccounting and ERP
Where a parsed invoice or purchase order has to land.
QuickBooks, Sage, NetSuite, SAPE-commerce
Where search, recommendations and product content meet a buyer.
Shopify, WooCommerce, BigCommerceYour own application
Where the feature is actually going, which is usually the hardest connection of the set.
a custom application, a portal, an in house systemModel providers
Where the per use cost comes from, chosen rather than inherited.
named in the scope, with the region named with it
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.
Asked and answered
Questions peopleactually ask.
-
How do we stop it saying something wrong?
By grounding it in your approved material, scoping what it is allowed to discuss, escalating what it cannot answer, and scoring it against a test set of real questions before launch and after every change. We also design the failure case, which is a person, rather than pretending there is not one.
-
What does it cost to run?
There is a per use cost, and we make it visible from the first month rather than burying it. It is estimated during scoping from your real volumes and reported monthly. Where a cheaper approach gives the same answer, we use the cheaper approach.
-
Our data is not organized. Can we still do this?
Sometimes, for a narrow first feature, and the work of organizing usually pays for itself anyway. What we will not do is scope an assistant on top of material that cannot support it and let you discover that after launch.
-
How is this different from an agent?
A feature makes one task easier inside your product. An agent is given a goal and carries work to the end across more than one system, stopping at the decisions you reserve. If the work currently waits in a queue for a person, you want the parent service rather than this page.
-
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.
-
How do we know it is working?
The evaluation set. Real questions, scored before launch and re-scored after every change, alongside reporting on use, escalation rate and the effect on the task itself. A feature nobody scores is a feature nobody can defend in the second year.
-
What does it cost to build?
The build price is set after the discovery call and sent in a written proposal, because an honest number needs the scope, and here the scope depends mostly on what state your material is in. The number is written into the signed scope and does not move once it is signed.
Three pages next to this one
Where thissits.
-
Agentic Operating Systems
The whole of it. A feature makes one task easier. An agent carries work to the end across systems and stops at the decisions you reserve, and the pillar page is where the difference is argued properly.
Agentic Operating Systems -
Integrations and Data
Grounding needs material, and material is usually spread across systems that disagree. Where the feasibility check comes back thin, this is the project that makes the feature possible.
Integrations and Data -
Web Applications and Portals
A feature has to live inside something. Where the product it belongs in does not exist yet, the application or the portal is the build and the feature is a later phase of it.
Web Applications and Portals
Close
Two ways to start.Both end with a document you own.
Book a discovery call
For when you can name the task and want the scope before the spend. A discovery call with the people who own the outcome. We check what material exists, pick the task where intelligence would change the result, and afterwards you get a written proposal with a scope, a price and a timeline you can sign or walk away from.
Book a discovery callRequest 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 auditKnow 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? Talk to the demonstration in your browser for three minutes, or paste your own address and hear it answer as your business. No form and no booking, and the transcript arrives by email a minute later.
Hear it work
Intelligence inside the task.
HUREAL / Material studies