AI agents that answer customers and act inside your systems

A classic chatbot runs on a decision tree - press 1 for pricing, 2 for support - and breaks the moment a customer phrases something nobody scripted. An AI agent understands an open question, retrieves the answer from your knowledge sources, and can carry out an action: opening a lead, booking a meeting or checking an order status instead of pointing at a form. The practical difference is that an agent finishes tasks while a bot only routes them. That difference is also what makes it more expensive to build, because an action that changes data needs permissions, an audit trail and a way to undo it.

A language model is built to produce an answer even when it has no source, and in a business deployment that is the real risk. We restrict the agent to your material only: pricing, service terms, catalogue and procedures. When a question has no source behind it, the defined behaviour is to say so and pass the conversation to a person. Before launch we run a set of deliberately awkward questions to find where it gives way. The reason this matters is simple: a price or a commitment the agent states to a customer is a statement made in your name, and the gap between a wrong answer and a missing one is the gap between a complaint and a follow-up call.

Yes, and Hebrew is precisely where many off-the-shelf agents fall down. Hebrew text arrives with mixed full and defective spelling, heavy use of abbreviations, product names in Latin script in the middle of a sentence, and RTL directionality that affects how replies render in WhatsApp and on the site. An agent built in English and translated afterwards answers correctly in a demo and breaks on how an Israeli customer actually writes. We therefore test on real enquiries from your business rather than on sample questions, and that is often the stage where it emerges that the price list itself is written in a way nobody can answer from.

To the systems you already run. On the enquiry side that is usually WhatsApp Business and the chat on your site; behind them a CRM, a calendar, an Israeli invoicing system such as Green Invoice, iCount or Rivhit, and your product or order data. Each connection is given a narrow permission: the agent can read an order status but not change a price, open a lead but not delete a customer. Every action is written to a log with its time, its conversation and its result, so afterwards you can check exactly what happened rather than relying on a model to recall it.

The handover rule is written during discovery, not improvised at runtime. The agent passes to a person when the customer asks for one, when the subject is a refund, a complaint or a legal matter, when anger or distress is detected in the wording, and when three consecutive replies have failed to resolve the issue. The handover carries the full transcript, so the customer does not tell the story from the beginning - that is the point at which most deployments irritate people more than they serve them. Outside working hours the agent collects the details, states when someone will come back, and opens a task rather than leaving the enquiry hanging.

The timeline follows the number of actions the agent performs far more than the number of questions it answers. An agent that answers from a price list and service documents and hands off to a person is a comparatively short project. One that books meetings, opens CRM records and updates order statuses needs permission design, failure handling and testing, and takes longer. In either case we start with a pilot on part of the traffic: read real transcripts, correct, and only then widen. That stage looks like a delay, and it is the thing that stops the agent meeting every customer with the same mistake.

Pricing follows the scope of discovery and the number of system connections, which is why we do not publish a single figure for this service - one number would not survive contact with two different projects. What is worth knowing in advance is the shape of the cost: a one-off build, alongside a monthly running cost covering model usage and maintenance. Model cost grows with conversation volume, so we present it as a range against an estimated volume rather than a fixed sum. In the discovery call we will also tell you the less comfortable version: whether your enquiry volume is too small to justify an agent at all.