METALCORE GLOBALAI Systems

Reference designs · Example, not client cases

AI agent use cases: four reference designs, not case studies.

Each design takes an ordinary operational problem — an enquiry, a support queue, an order, a report — and walks the six decisions a build has to settle. None of them describes a specific client, a real deployment or a measured result, because we do not publish those.

This page is a method example, not a client case study. The four designs were written by us from patterns in enquiry handling, support, order operations and reporting. No client, deployment, region or performance figure is described here.
Request a quote ↗

How to read this page

Same six headings, every time.

Every design below uses the same six headings, so you can compare them without re-reading. Typical situation is the operating context we assume — deliberately generic, written from the shape of the problem rather than from one company. Where it usually breaks describes a mechanism, not a complaint. Where the human stays is the part we treat as non-negotiable: who approves, how low confidence escalates, and what is never sent automatically. What we deliver lists the artefacts you would receive. How we'd measure it gives the readings we would agree before a build starts. What we would not do is the scope we exclude.

The Example label means exactly that. There are no client names, no measured results and no performance figures anywhere on this page, because we have none we are permitted to publish. Where a number appears, it is either a range of time (1–2 weeks) or the definition of a measurement (cost per task, exception rate) — never an outcome we claim to have achieved.

The four reference designs

Reference design 01 Example

Inbound RFQ to reviewed quote.

Typical situation

You sell to businesses, so most enquiries arrive by email or messaging app, in the buyer's own format, with quantities in mixed units. Three or four people can answer pricing questions, and the current price list lives partly in a spreadsheet and partly in their heads. A quote is assembled by hand from an older quote that looked similar.

Where it usually breaks

Not at the writing — at the reading. A missing specification, an unusual unit, a destination the price list does not cover: each one needs a person to notice it, and noticing is the step that fails when ten enquiries arrive in the same hour. So the enquiry waits, or leaves as a quote built on an assumption nobody wrote down.

Where the human stays

Pricing approval does not move. The agent extracts the requirement, flags what it could not read along with a confidence score, applies only authorised prices, and drafts. A named approver — sales lead or commercial manager, agreed per client — reviews before anything leaves. Any line below your margin floor, any new customer and any non-standard term routes to that person and is never sent automatically.

What we deliver

  • An extraction queue that keeps the source sentence beside every field it filled
  • A pricing rule table — units, delivery terms, margin floors — held in one editable place
  • Approval routing with named approvers and a full revision history
  • An evaluation set built from your past enquiries, with the correct reading recorded
  • A quote template, a follow-up schedule and a status history per enquiry
  • A written list of what the agent must refuse to quote
  • A runbook naming who owns the rule table after handover

How we'd measure it

Four readings, agreed before build: extraction accuracy on the evaluation set, the share of enquiries that reach an approver without a correction, elapsed time from enquiry received to quote approved, and cost per processed enquiry including review minutes. Your numbers depend on your volumes, not ours.

What we would not do

We will not send a quote without a human approval step, and we will not let the agent invent a price, a lead time or a stock position it cannot read from your data. We do not replace your price list with a model's judgement, and we do not take a percentage of the orders this produces.

Reference design 02 Example

Multilingual first-line customer service.

Typical situation

Buyers write in English, Arabic and Chinese, often into the same inbox, often outside your working hours. One or two people answer everything: product questions, stock, delivery status, complaints, and the occasional serious enquiry that should have reached sales three days earlier. The answers exist — in a catalogue, a policy document, a specification sheet.

Where it usually breaks

Two ways. The answer is right but the hand-off is wrong: a commercial enquiry receives a polite general reply and dies there. Or the answer is confidently wrong because a policy changed and the document the agent reads was not updated. Neither failure looks like a failure from outside — the customer simply stops replying.

Where the human stays

Three rules are agreed per client before launch: what the agent may answer alone (documented facts, order status, standard terms), what it must draft and hold for review (anything carrying a price, a commitment date or an exception), and what it must escalate immediately (complaints, legal language, named accounts). Low confidence goes to a takeover queue carrying the whole thread, not a summary of it.

What we deliver

  • An answer policy table with three columns: answer alone / draft and hold / escalate now
  • A knowledge base built from your own documents, each with a named owner and a review date
  • A human takeover queue that carries the full thread and the sources used
  • Source citations on every reply, so a wrong answer traces back to a document
  • Escalation rules set by customer value and by confidence
  • The language set: English, Chinese and Arabic
  • A recurring list of questions the agent could not answer

How we'd measure it

Answer accuracy on a graded set of real past conversations, the share of conversations resolved without a human reply, the share of escalations that reached the right person on the first attempt, and cost per conversation including review time. Your numbers depend on your volumes, not ours.

What we would not do

We will not let it negotiate, confirm a discount, accept a return or admit liability. We do not build it to imitate a named employee's voice, and we do not promise it reduces headcount — the first version usually changes what your team spends the day on, not how many people there are.

Reference design 03 Example

Order and document handling.

Typical situation

An order arrives as a purchase order PDF, a spreadsheet, or four lines of email. Someone retypes it into the ERP, checks the quantities against the confirmation, sends the confirmation, chases the forwarder, files the invoice, and remembers to follow up when a delivery date slips. The same five steps, several hundred times a month.

Where it usually breaks

Silence. A document that failed to extract does not announce itself — it becomes a record that is missing, found weeks later during reconciliation. A confirmation that was never sent looks identical to one that was. And when the person who owns the queue is away, everything half-finished is invisible to everyone else.

Where the human stays

Extraction is proposed, not committed. Any document whose fields fall below the confidence threshold, any quantity or price that contradicts the order, and any amendment after confirmation goes to an exception queue with the original document beside it. Approvers are named per document type — finance for invoices, operations for delivery changes — and nothing that alters a confirmed order is sent automatically.

What we deliver

  • An exception queue where every unresolved document lands, with the source file attached
  • Extraction rules per document type, versioned, with the change history kept
  • Confirmation and reminder templates with explicit send conditions
  • An approval matrix by document type and by order value
  • A reconciliation report: what arrived, what was structured, what is still open
  • A supervisor view showing queue age and backlog, not just totals
  • A runbook and a short training session for whoever owns the queue

How we'd measure it

Exception rate per document type, the share of documents structured without a human touch, the age of the oldest open item in the queue, and cost per processed order including exception handling. Your numbers depend on your volumes, not ours.

What we would not do

We will not build a system that silently discards a document it cannot read. We do not auto-approve payments or amend a confirmed order without a person, and we do not take over your ERP — we write into it through its own API, under permissions you grant.

Reference design 04 Example

Enquiry-to-report.

Typical situation

Management wants a weekly picture: how many enquiries arrived, which are worth chasing, where deals stalled, which customers went quiet. Producing it means asking three people, exporting from two systems, and reconciling definitions nobody wrote down. The report appears on Thursday, describes last week, and gets argued over rather than used.

Where it usually breaks

In the definitions, not in the data. Two teams count an enquiry differently; a deal closed in one system is still open in another; a total changes when someone re-runs the export. The monthly argument ends up being about whose figure is correct, not about the business.

Where the human stays

Definitions are signed off by a person, not inferred by the system. Before anything is scheduled, the report owner agrees each metric in writing — what counts, which source wins, what is excluded, and who may change it. When two sources disagree, the report shows the conflict and the number of affected records instead of choosing silently. The owner reviews each issue before it is distributed, until the definitions hold.

What we deliver

  • A metric definition sheet: name, formula, source system, owner, change log
  • Scheduled daily, weekly and monthly reports, delivered to email, chat or a management view
  • A source-conflict log that counts the affected records rather than hiding them
  • A backfill of the same report from historical data, so new and old periods are comparable
  • Enquiry and opportunity scoring with the rules visible to the people being scored
  • Conversion and cost-per-task tracking on the same definitions
  • The definition sheet handed over as a maintained document, not a slide

How we'd measure it

Refresh reliability — whether the report arrived and reconciled against source totals; definition drift — how many metrics changed definition without a logged reason; elapsed time from period close to report delivered; and the number of corrections requested after distribution. Your numbers depend on your volumes, not ours.

What we would not do

We will not produce a dashboard nobody owns. If nobody will sign the definitions, we stop and say so before building. We do not blend two disagreeing sources into one confident number, and we do not present a forecast as a result.

Common to all four

Four artefacts come out of every build.

Whatever the scenario, these are what an auditor, a new hire or your own engineer would ask for.

  • The written scope. What the system does, what it must never do, and the threshold that decides whether it goes live.
  • The evaluation set. Real cases from your history with the correct answer recorded, so accuracy is a measurement rather than an opinion.
  • The approval matrix. Every action the system can take, and the named role that must authorise it.
  • The runbook. How to operate it, how to change a rule, what to do when the queue backs up, and who to call.

All four are handed over, not withheld. Source code, prompts, architecture notes and runbooks go to your accounts and repositories, and ongoing support is optional and separately priced — continuity should be a choice, not a dependency.

Before we can quote

Four things, and none of them is a document.

  • One process, named precisely. Not a department and not a strategy — one workflow with a start and an end, described by the person who performs it.
  • The person who runs it today. Half a day of their time in discovery is worth more than anything they could write about it afterwards.
  • Someone who can decide rules. Price floors, escalation boundaries, what must never be automated: these come from a person with authority, and they need to be reachable when we ask.
  • Real past cases. Twenty to a few hundred examples with the correct outcome recorded — that is what the evaluation set is built from. Messy cases are more useful than clean ones.

References

What we will and will not show you.

We do not publish client names, logos, deployment counts or quotations, and you will not find them anywhere on this site. Where a prospective client wants to speak to someone we have worked with, we will tell you in the first call whether we can arrange it — that depends on the other client's consent, not on our willingness. If we cannot, we will say so plainly rather than describing unnamed companies and letting you assume the rest.

Next step

Two ways to start, both cheap.

If you already know what you want built, send the workflow and we will quote a fixed first stage. If you do not, describe the process that consumes the most hours and we will tell you which of these four designs it resembles — or that it resembles none of them. Either way: one business day to reply, then a 30-minute call if it looks like a fit.

Request a quote ↗ Tell us which process costs you the most

Or call +971 52 679 1996