The four layers of a practical AI stack

A practical stack — a set of tools that work together — can be split into four layers. Each solves a different problem. Trouble starts when you try to hand all the tasks to a single layer.

Table 1  How responsibilities are divided between tools

Source systems

A source system stores the data on which the company actually operates. In ecommerce this includes orders, inventory, prices, payments, documents and competitor data.

In our example, ZYNQ provides information about products, orders, inventory, shipments and documents. Dealavo monitors the market and runs controlled repricing. GA4 shows traffic and conversion. The agent should not guess any of these values or create an alternative copy of them without a clear need.

Automation

Automation is responsible for moving data and running predictable processes. If a rule can be written as a clear instruction, a classic workflow will usually be cheaper and easier to control than an agent.

• When an order status changes, send a message to the customer.
• Every morning, pull the sales report and save it to a defined location.
• When stock falls below a defined level, create an alert.
• After a recommendation is approved, push the new price to the system.
• Log the result of every operation and notify the process owner on error.

AI agent

An agent is useful where a simple rule is not enough. It can combine information from several systems, spot an unusual relationship, summarize the situation and propose the next action. However, it should rely on data coming from the right systems, not on its own memory or random search results.

In processes that affect margin, inventory or the customer, you need limits and approvals. A human sets the goal, the agent analyzes the situation, automation moves the data and the specialized SaaS executes the operation.

Custom applications

Rapid app-building platforms work well as the last layer of the system. You can use them to build an approval screen for recommendations, a margin calculator, a department-specific report, a supplier portal or an inventory analysis tool.

The problem starts when such a panel gradually turns into a new ERP. First it only displays data, then it starts to edit it, then it stores its own statuses. After a while the team no longer knows which system holds the true information.

How to match the tool to the task

Choosing a tool should start from the type of responsibility. The higher the cost of an error and the more dependencies involved, the stronger the case for a mature system.

Table 2  Quick decision matrix

Build the pieces that come from the company’s unique way of working. Hand standard and critical processes over to mature systems.

An operational example with slow-moving stock

Suppose a product has barely sold in the last 90 days. The manager has to check inventory, cost, sales, GA4 data and competitor prices, then calculate a discount, change the price and come back to the result.

In a well-designed stack, every element of the process has its own owner:

• ZYNQ provides stock level, cost, order history and sales velocity, and later shows the impact of the decision on inventory rotation.
• Dealavo shows the pricing landscape, competitor availability and a safe repricing range.
• GA4 provides traffic and conversion data; n8n or Make periodically collects the needed signals and triggers the analysis.
• The AI agent combines the information and prepares a recommendation together with its reasoning.
• A lightweight app shows the manager the proposed change, and once approved, the proper pricing system executes it within the defined boundaries.

120 units of product X are left in stock. In the last 30 days 4 units were sold. The price is 12 percent above the market median, and the minimum margin allows a reduction of 9 percent. I suggest testing a new price for 14 days. The change requires approval.

What matters is not just that the agent produced a recommendation. The data lineage, how the limit was computed, and the system that will safely apply the change — those are what count.

Rules that should stay out of the prompt

Language models are good at interpreting ambiguous information. They should not be the only mechanism responsible for rules the company must always enforce. The following should stay out of the prompt:

• minimum acceptable margin and maximum discount
• tax rules and document issuing
• available-stock checks
• user and agent permission limits
• unambiguous conditions for status changes
• protection against running the same operation twice
• limits on the number and value of changes within a given time window

A prompt can help pick a strategy and explain the decision. If a rule must be strictly enforced, it should run as a deterministic rule in the system.

The most common mistakes when building custom tools

Too broad a scope for the first version

A first successful prototype tempts you to pile on features. A calculator becomes a panel, the panel becomes an order system, and the order system becomes a homegrown ERP. The first rollout should solve one problem for a specific group of users.

No single source of truth

If stock, price or status is stored in several places, differences will show up sooner or later. For every type of data you need to designate a master system.

Granting write access too early

The agent should start by reading data and preparing recommendations. The right to perform limited operations should be granted only after you’ve verified the quality of its work.

Automating a disorganized process

If the team cannot describe the rules of the process, AI will just reproduce its ambiguities. First establish roles, conditions and the expected outcome.

No owner and no action history

Every small tool needs an owner. The company should also know what data the agent used, who approved the recommendation, what was executed and what the effect was.

How to start without a big project

Your first project should not be an agent that runs the whole ecommerce operation. A better start is a daily list of products that need a pricing decision, or a report of orders at risk of being delayed.

1. Pick one repeatable decision that today requires working across several systems.
2. Define the source of truth for every parameter you need.
3. Check the availability of APIs, exports and webhooks.
4. Build the first workflow in read-only mode.
5. Ask the agent to prepare recommendations together with their reasoning.
6. Add a simple approval screen and operation limits.
7. Measure time saved, recommendation quality and business outcome.
8. Only after the process is verified, expand the scope of autonomy.

How SaaS should change

SaaS vendors have to prepare for a situation where their system is used not only by humans. More and more operations will be initiated by an agent acting on a user’s behalf.

A modern platform should expose:

• a complete and well-documented API
• webhooks that report events
• precise permissions for data and operations
• limits on the number and value of changes
• a test environment and a simulation mode
• an action history with the reasoning behind each operation
• an approval mechanism and the ability to safely roll a change back
• data prepared for use by external apps and agents

SaaS should not fight with the apps built by its customers. It should become their stable foundation. The customer then builds the final, most individual layer of the process on their own, but doesn’t take over responsibility for the whole infrastructure.

Build what is unique to the company

AI tools now let you create applications that until recently would have required a full team. It’s worth taking advantage of that, especially for reports, internal interfaces and processes specific to your organization.

That doesn’t mean every company should build its own price scraping, warehouse system, order handling or financial mechanisms. These areas require ongoing maintenance, domain knowledge and accountability for errors.

The most sensible model is hybrid. The line can be drawn simply:

The same AI models are available to many companies. The edge comes from how you combine them with good data, clear rules and a process that has defined boundaries. There’s no point in building your own ERP just because it has become technically possible. It’s worth building the part of the system you can’t buy, because it comes from the company’s unique way of operating.