AI Agents on Top of Israeli Business Systems: What Works and What Doesn't

A recurring question: can you put an AI agent on top of the business systems - Priority, the invoicing system, the CRM - and let it work? The short answer: the agent acts only through the same API a script would use. If a system has no API, the agent has nothing to call. Intelligence does not create an access route.

What an AI agent is, and what it is not

There is a common confusion worth unpacking: an agent is not an integration, and it does not replace one.

An agent is a model given a list of possible actions, which decides which to invoke and invokes it. Those actions are code you wrote - API calls, queries, sending a message. The agent picks between them; it does not invent them.

From which two conclusions follow that decide feasibility:

• If a system has no interface, the agent has no hands. There are routes into a closed system, but they are the same routes at the same cost with or without an agent.
• The integration work remains. Connecting the systems is a prerequisite, not something the agent saves you.

The split that decides whether this works

This is the central decision: what you give the agent and what you leave to code.

The principle: an agent is good at ambiguous input and a reasonable outcome. It is not suited to an action that must be exact and irreversible.

Put more sharply: where money moves, an agent that usually gets it right is worse than code that always does. An invoice issued twice is a real accounting problem; there is no flexibility gained that justifies it.

Reads versus writes

The most practical separation:

Reads - grant freely

An agent that reads data and returns an answer is a relatively safe case. A wrong answer is annoying, but it changes nothing in the system.

That is where the value is real: "how much did this customer order this year", "which orders are stuck", "what changed against last month". Questions that today require someone who knows where to look.

Writes - gate them

A write to a financial system needs one of two things:

• Human approval - the agent prepares, a person approves.
• A strictly bounded action - not "update what is needed" but one action with defined parameters and validation in the code, not in the prompt.

The test: if the agent chooses wrongly, how long until you find out and fix it? If the answer is "we would not know" - that is not an action you give it.

Four problems specific to Israel

1. Hebrew data quality

An agent looking up a customer depends on string matching - and Hebrew text in business systems is dirty: double spaces, invisible directional characters, the same name in two spellings, inconsistent encoding between systems.

The result: the agent does not find a record that exists, or finds the wrong one. And then the model gets blamed, while the problem is in the data layer.

What that means in practice: cleaning and normalisation before connecting an agent. It is boring work that determines the outcome more than model choice does.

2. The agent does not know your rules

A model knows how businesses work in general. It does not know that a particular customer has unusual payment terms, that a product is not sold to a certain region, or that an order above a certain amount needs approval.

That knowledge has to reach it - as documents it retrieves from, or as checks in code. A clear preference: a rule with a financial consequence belongs in code, not in a prompt. A prompt is a request; code is enforcement.

3. Cost and latency

Every call to a model costs money and takes time. An agent running on every event in an active system produces a bill you did not forecast.

A question worth asking early: does this case need a model at all? Much of what gets called an "agent" is an if-statement that works perfectly, free, and predictably.

4. Where the data goes

An agent sending customer data to an external service moves information out of the business. That should be a conscious decision - what is sent, where, and what is retained there.

Not every case requires sending whole records. Often you can send the question without sending the database.

Where it does work well

After all the caveats - there are cases where an agent delivers real value:

• Free-text input. A customer writes on WhatsApp "can I get three more of what I ordered last month". Extracting intent from that is exactly the work ordinary code does badly. The agent extracts; the code executes.
• Questions about data. Turning a question in Hebrew into a query, and returning an answer. Read-only, therefore safe.
• Extraction from documents. A supplier invoice, a delivery note, an order in free format. With human approval before it enters the system.
• Drafting. A reply to a customer, a meeting summary, a description for a quote.
• Classification and routing. Deciding where an enquiry goes - a wrong outcome costs a re-route, not money.

What they share: the agent works on the ambiguous part, and the code performs the action.

Build order

1. Confirm there is an interface to the relevant systems. Without it there is no project. A map of the systems helps establish what exists.
2. Clean and normalise the data - especially Hebrew names and identifiers.
3. Build the actions as ordinary code with validation, and confirm they work on their own.
4. Only then attach an agent that chooses between them.
5. Start read-only. Run it for a period and see where it gets things wrong.
6. Open writes gradually, with human approval first.
7. Log every decision - what was asked, what was chosen, what happened. Without that you cannot diagnose.

And on budget: most of the cost is in integration and data cleaning, not the AI layer. Budgeting only for the clever part is budgeting for the small part.

The broader assumptions about AI agents in business automation apply here in full - what changes in Israel is Hebrew data quality and a relatively closed interface landscape.