Generative AI development for the work that is not a chatbot and not an agent
Most generative AI in a working business is not something anyone talks to. It is a model doing one bounded language job inside software you already run: turning fifty pages into a two-paragraph summary with a fixed shape, pulling eleven fields off an invoice, sorting nine thousand documents into four buckets, drafting a letter a person then edits and signs. No conversation surface, no autonomy. This page is about that.
Which of our pages do you actually want?
Four of our services use the same underlying models and they are genuinely different products. Read this table before reading the rest of the page, because if your answer is in one of the other three rows we would rather send you there than sell you this.
| If you want | The page you want | What makes it that and not this |
|---|---|---|
| Software that decides something and then acts on it in your systems | AI agent development | It has autonomy. It picks between options and writes to systems on its own, inside rules you set. |
| A thing your customers or staff type questions into | AI chatbot development | It has a conversation surface. The output is a reply to a person, in a thread, in real time. |
| Answers to questions about your own live business data | RAG chatbot development | The hard part is retrieval: finding the right records in your CRM and ledger before generating anything. |
| A workflow moved off a person: trigger, steps, retries, alerts | AI automation | The hard part is the plumbing around the model, not the model call itself. |
| One language task, done to a specification, at volume, inside your existing software | This page | No conversation, no autonomy. Input goes in, a specified output comes out, a person or a system uses it. |
The line between the last two rows is the one worth stating plainly, because it is where most confusion sits. Automation owns the workflow: what triggers it, what happens next, what to do when a system is down. This page owns the model step inside it: what exactly the model is asked to produce, how that output is constrained, and how you find out when it is wrong. Plenty of projects need both, and when they do they are quoted as one piece of work rather than two.
The four jobs this covers
Each one is a task with an input, an output specification, and a way to grade the result. If a job you have in mind does not have all three, it is not ready to be built, and our assessment exists to say so before you spend anything.
Document generation and drafting inside a tool you already use
A quotation assembled from the line items already in the deal. A monthly client report written from the figures in the ledger. A tenancy notice, a scope of work, a rejection letter that has to be polite and specific. The interface is a button inside HubSpot, Salesforce, monday.com or your own application, and the output lands in a draft state that a named person edits and sends. The generation is automated. The sending is not, which is the same rule we apply on every page here.
Summarisation to a fixed shape
The useful version of summarisation is not "make this shorter". It is "return these six fields, in this order, at this length, and say when the source does not contain one of them". A call transcript into a structured account note. A supplier contract into its termination clause, notice period, auto-renewal and liability cap. A week of a shared mailbox into a briefing that names who is waiting on what. A summary with a defined shape can be checked against the source; a free-form paragraph cannot.
Extraction from unstructured input
Invoices, purchase orders, contracts, delivery notes, application forms, bank statements, identity documents. What arrives is a scan, a photo, an email body or a PDF nobody controls the layout of. What is wanted is a row of typed fields. This is the job where generative models displaced template-based OCR outright, because a model reads a layout it has never seen before, and it handles the Arabic and English mix that UAE paperwork actually arrives in.
Classification and routing at volume
Sorting thousands of items into a fixed set of categories: support tickets by cause, documents by type, transactions by expense category, applications by completeness. Volume is what makes this a different engineering problem to the others. At three items a day a person is cheaper. At nine thousand a month the cost of the model call, the cost of getting it wrong, and the cost of finding out you got it wrong all become the design.
Why the output specification is the whole job
Every one of the four jobs above lives or dies on one question: what exactly is the model allowed to return? Get that right and the rest is ordinary software. Get it wrong and you have built something that works in the demo and produces unparseable output on the fourth Tuesday of the month.
The model vendors now solve half of this at the API level. Anthropic's structured outputs constrain the response to a JSON schema you supply through constrained decoding, so a schema-violating response cannot be produced rather than being unlikely; the feature is supported on Claude 4.5 and later models. The documented limits matter as much as the guarantee: recursive schemas are not supported, numerical constraints such as minimum and maximum are not supported, and string length constraints are not supported. Compiled grammars are cached for 24 hours, and the first request with a new schema carries extra latency while the grammar compiles. (Verified July 2026, against Anthropic's structured outputs documentation at platform.claude.com.)
Read that list carefully and you have the honest version of the pitch. The schema guarantees the shape, not the truth. A model that must return a number between 1 and 5 will return a number, and the API will not check that it is between 1 and 5, because numerical constraints are outside what the schema enforces. That check belongs in your code, and so does everything else that decides whether the answer is right: the confidence threshold below which the item goes to a person, the arithmetic that must reconcile before an extracted invoice total is accepted, the list of values a field is allowed to take.
So the deliverable is not a prompt. It is a schema, a validation layer that runs after the model and can reject its output, a queue for everything that failed validation, and a graded test set of real examples from your own documents that we run before and after every change. Without the test set there is no way to tell an improvement from a regression, and that is the single most common thing missing from generative work that has already been built by someone else.
What it costs to run at volume
Volume work is priced per token by the model vendor and billed to you, not to us. For anything that does not need an answer in the same second, the batch route is half price. Anthropic's Message Batches API applies a 50% discount to both input and output tokens, most batches complete in under an hour, a batch is limited to 100,000 requests or 256 MB whichever comes first, requests expire if the batch has not completed within 24 hours, and results stay available for 29 days. At batch rates Claude Haiku 4.5 is USD 0.50 per million input tokens and USD 2.50 per million output tokens. (Verified July 2026, against Anthropic's batch processing and pricing documentation at platform.claude.com.)
Here is the arithmetic on a real shape of job, so the number means something. Say you classify 20,000 documents in a month, each about 1,500 input tokens, each returning a 40 token structured answer. That is 30 million input tokens at USD 0.50 per million, which is USD 15, plus 800,000 output tokens at USD 2.50 per million, which is USD 2. Seventeen dollars, about AED 62 a month, for the model calls.
Which tells you where the money actually is. It is not in the tokens. It is in the build, in the review queue somebody has to staff, and in what a misclassification costs you when nobody catches it. We would rather you knew that before commissioning anything than discover it after, and a payback case that depends on the token bill being the main cost is a payback case we will argue with.
When the documents cannot leave the country
Sending a contract or an invoice to a model API is a transfer of whatever is inside it, and in the UAE that is sometimes a question with a legal answer. Personal data is governed by Federal Decree-Law No. 45 of 2021 on the protection of personal data, which applies to the processing of personal data inside or outside the country and sets out the requirements for cross-border transfer. (Verified July 2026, against the UAE Government portal page on data protection laws at u.ae.) Health data has its own stricter regime, which we set out in detail on the healthcare page.
Where a class of document cannot go to a hosted endpoint, the model runs on infrastructure you control. Open-weight models are good enough for extraction, classification and structured summarisation, which are the jobs on this page, and there is a locally relevant option: the Technology Innovation Institute in Abu Dhabi released Falcon-H1 Arabic on 5 January 2026 in 3 billion, 7 billion and 34 billion parameter sizes with context windows up to 256K tokens, reporting Open Arabic LLM Leaderboard scores of 61.87%, 71.47% and 75.36% respectively. (Verified July 2026, against the TII announcement at tii.ae.) The weights are published for download under the Falcon-LLM License, which is a source-available licence with an acceptable-use policy rather than an OSI-approved open source licence. Read it before you deploy; we are not summarising its terms here. (Verified July 2026, against the Falcon LLM licence terms published at huggingface.co; read the licence yourself before deploying, we are not summarising its terms here.)
Self-hosting is not free and we will not present it as the obvious choice. A 34 billion parameter model needs a GPU, which is a different order of hosting cost to the droplet a hosted-API build runs on, and you own the patching. The trade is control for cost, and it is worth making only when a constraint forces it or when your volume is high enough that the arithmetic turns. We do that arithmetic with you rather than assuming the answer.
Illustrative scenarios
These are illustrative, not client accounts. Telora Labs was founded in 2025 and does not publish client names, so nothing below describes a company we worked with. Each is written as what a build would do.
"Every quotation goes out as last quarter's document with the numbers changed by hand."
The build would put a button on the deal record in HubSpot or Salesforce that assembles the quotation from the line items, prices and terms already stored against that deal, then writes the covering scope of work to a section structure your commercial lead approved once. Anything the record does not hold would come back as a marked gap rather than a plausible sentence: a delivery date nobody has agreed, a site condition nobody has confirmed. An invented delivery date written confidently costs more than drafting the document by hand. The draft lands in the deal owner's queue under their name, and a person sends it.
The document stops being a copy of the last one. What gets promised, and to whom, stays a commercial decision.
"Nobody can say which supplier agreements auto-renew next quarter without opening all of them."
The build would read each agreement and return the same fields every time: parties, start date, term, notice period, renewal behaviour, termination rights, liability cap and governing law, with each field carrying the clause it was taken from so a person can check the summary against the source instead of trusting it. Where an agreement is silent on a field, the output would say so rather than fill in what is usual, because a missing notice period is a finding and a blank is not. The fields land in the register finance or legal already keeps, and anything the model marked ambiguous goes to a review queue with the clause text attached.
Reading every contract becomes reading the handful the summary could not settle.
"Account managers write the same monthly client report from the same four dashboards."
The build would pull the month's figures from the systems that hold them, generate the narrative to a fixed section structure, and put a draft in the account manager's queue with every figure traceable to the query that produced it. Where a number moved sharply, the draft would say so and leave the explanation blank rather than inventing one, because the explanation is the part the account manager knows and the model does not. Nothing reaches a client without a person having opened it.
Assembly is automated. Judgment and sending are not.
Where this goes wrong
The demo passed on ten examples
Ten examples is roughly the number at which everything works. The exceptions live in the long tail: the scanned page at an angle, the credit note formatted as an invoice, the supplier who writes the total in words. We build the test set from your real documents, including the ugly ones, before agreeing what the build is.
Nobody defined what correct looks like
If two people in your team would grade the same output differently, there is nothing to measure and no way to know whether a change helped. Settling that disagreement is scoping work, and it is cheaper than discovering it three weeks in.
The review queue has no owner
Every build here produces items the model could not resolve. That is a feature, not a defect, and it only works if a named person looks at the queue on a schedule. Without an owner the queue grows until someone quietly starts approving it in bulk, which is worse than not having built the thing.
The document format changed and nothing said so
A supplier switches invoicing software, a form gains a field, a portal changes its export. Extraction accuracy falls and the failure is silent because the output still parses. Monitoring the rate at which items fail validation, and alerting when it moves, is what catches this, and it ships as part of the build rather than as an upgrade.
The model got swapped and nobody re-ran the tests
Model versions are deprecated and retired on the vendor's schedule, not yours. Pinning a version and re-running the graded test set before moving is a small piece of process that prevents a category of regression nobody would otherwise attribute to the right cause.
What a generative AI build costs
Fixed price, agreed before work starts, in the same bands we quote for every build. What moves a project between bands is the number of document shapes involved, whether the output has to reconcile against something, and whether the model can run on a hosted API or has to run on your own infrastructure.
| Band | Scope | Price (AED) | Indicative timeline |
|---|---|---|---|
| Single task | One document type, one output schema, one review queue | 10,000 to 20,000 | 2 to 3 weeks |
| Multi-system | Several document types, validation against a system of record, writing results back | 20,000 to 35,000 | 3 to 5 weeks |
| Complex | Compliance constraints, a self-hosted model, or a heavy integration surface | 35,000 to 50,000 | 5 to 8 weeks |
The dirham is pegged at roughly 3.67 to the US dollar, so that is about USD 2,700 to 13,600. Model and hosting costs are billed to you by those vendors and sit outside the build fee; the arithmetic for both is broken down in what an AI agent costs in Dubai. Ongoing changes and monitoring run on a monthly retainer. How we work covers scoping, handover and what happens after launch.
Send us three real documents and what you want out of them
Three is enough to tell you whether this is a two week job or a two month one. Include the awkward ones. We will come back with the output schema we would build, the checks we would run after the model, and a band from the table above.
hello@telora.dev