AI and LLM development
A language model is a component, not a product. The interesting engineering in an AI feature is almost never the model call. It is what you feed it, what you do with what comes back, what it costs per user, and what the system does when the model is confidently wrong.
We build LLM features inside real products: systems that already have users, data and consequences. That is a different discipline from building a demo, mostly because a demo is allowed to be wrong.
What we build
Retrieval
Answers drawn from your own documents, with the source attached.
Extraction
Unstructured input turned into fields a system can act on.
Assistants
Models that do the work, not only describe it.
Retrieval over your own content
Most useful AI features are a retrieval problem wearing a generation costume. The model is only as good as what you put in front of it, so the work is in chunking, indexing, ranking and knowing when the honest answer is that nothing relevant was found.
We would rather a system say it does not know than produce a fluent answer assembled from the three least irrelevant documents. That preference has to be built in deliberately, because the default behaviour of every model is to answer anyway.
Structured extraction
Turning documents, emails and messages into fields a system can act on: invoices into line items, enquiries into leads, free text into a category. This is where LLMs earn their cost most reliably, because the output is checkable. You can validate a date, a total and a currency, and reject what does not parse.
Assistants that can actually do something
An assistant that can only talk is a search box with worse latency. The value is in tool use: looking up an order, starting a return, booking a slot. That means every tool needs permission checks, an audit trail, and a clear boundary between what the assistant may do on its own and what needs a human to approve it.
The parts people underestimate
Cost is a design decision
Per request cost is set by architecture long before it is set by model choice. How much context you send, whether you send it every turn, what you cache, and whether a cheaper model could have handled the ninety percent of requests that are simple. We design the routing first and pick models second, and we tell you the expected cost per thousand interactions before you commit.
Latency is a product problem
Users tolerate a slow answer very differently depending on whether something is visibly happening. Streaming, optimistic UI and honest progress are part of the engineering, not polish added afterwards. So is deciding which calls happen while the user waits and which happen in a queue behind them.
Being wrong is a feature requirement
Every LLM feature needs a defined answer to: how do we know when it was wrong, what does the user see, and what does it cost us. For a summarisation feature the answer might be a shrug. For anything touching money, stock or a commitment to a customer, the answer is a human in the loop and an audit trail. We insist on having that conversation before building, because retrofitting it means rebuilding.
Evaluation, or you are guessing
Without a test set you cannot tell whether a prompt change improved anything. We build a small evaluation set from your real cases early, so changes can be measured rather than argued about, and so a model upgrade is something you can assess rather than something that happens to you.
What we will tell you not to do
A fair number of the AI projects we are asked about are better solved without a model. If the input is structured and the rules are knowable, a rules engine is cheaper, faster, testable and never invents anything. If the real problem is that your data is scattered across four systems, an assistant on top of that mess will be confidently wrong in a new and more expensive way.
We would rather say that during discovery than build something impressive that quietly does not work.
How the work runs
Discovery establishes the use case, what a good answer looks like, what a wrong answer costs, and where the data actually lives. That produces an architecture, an expected running cost and an evaluation plan.
The first build is narrow on purpose: one workflow, real users, measured. AI features are unusually prone to looking finished in a demo and falling apart on the variety of real input, so getting to real input quickly matters more here than almost anywhere else.
Related
AI features are usually built on top of a platform that already holds the data, and reach the rest of the business through system integration. If the interface is the hard part, see UX and UI design.
Common questions
Which models do you use?
Whichever fits the task, the cost envelope and the data constraints, and we design so that choice can change. Model capability and pricing move faster than anything else in this stack, so being locked to one provider is a risk rather than a simplification.
Does our data go into training?
Not unless you decide it does. Which provider and which tier you are on determines this, it is a contractual question as much as a technical one, and we set it up explicitly rather than by default.
Can this run without sending data outside Israel or the EU?
Sometimes, depending on the task and the accuracy you need. Smaller self hosted models handle classification and extraction respectably. For open ended generation the gap is still real, and we will tell you honestly what you lose rather than sell you a private deployment that disappoints.
How much does it cost to run?
We give an expected cost per thousand interactions during discovery, and design to it. It is usually lower than people expect for extraction and classification, and higher than people expect for anything that sends large context on every turn.
What if the model gives a wrong answer to a customer?
That is a design question we answer before building. Depending on what is at stake it is a confidence threshold, a citation the user can check, a human approving before anything is sent, or simply not using a model for that step.
More services
Next
Tell us what you are building, or what is breaking.