Reasoning as the rootstock: why intelligence cannot be bolted onto a legacy ERP

In horticulture, the rootstock is the root system onto which a fruit-bearing branch is grafted. If the rootstock is weak, the graft may take - but the tree will never produce well. The fruit depends on the root.

The same principle applies to enterprise software. For the past three years, every legacy ERP vendor has announced an AI strategy: a chatbot on the side, a copilot for report generation, a suggestion tool for purchasing. These are grafts onto a rootstock that was never designed to reason. It was built to record data, not to draw conclusions from it. Its links to other software were built to read and write single records, not to carry context. Its security was built to decide who sees which row, not to control what an AI agent may do.

What AI-native means

When we say Kinnow is AI-native, we mean that Kinnow was designed from the start with agents as full participants in the work. This shows up in specific ways.

First, every record carries its background, not just its numbers. A journal entry in Kinnow does not just say "debit office supplies, credit bank, amount 14,500." It carries the source document, the approver's identity, the agent that proposed it (if any), how sure the agent was and the reasoning behind it. When another agent reads this entry - say, the Close Checklist agent checking for anomalies - it has the context it needs to reason about whether the entry looks right.

Second, every agent works within Veil, our privacy layer, which also sets the limits for each agent. Veil controls what each agent can see and do: which records it can read, which fields it can access, whether it can propose changes or only watch, and which of its work must wait for a person to approve. This is not an afterthought added on with access keys. It is built into the foundation, so every agent - whether built by Kinnow or by a customer - works under the same rules.

Why bolting on fails

A legacy ERP that adds a chatbot can answer questions about the data. But the chatbot reads the data through connections that were not designed for AI. It gets bare rows without the context: no reasoning behind them, no sense of how sure anyone was, no link to the source document. It can summarise, but it cannot reason about whether what it sees is correct, complete or consistent.

A copilot that generates reports can save time on formatting. But it cannot detect that the report's numbers include a duplicate entry posted by a batch job last Tuesday night - because it cannot see the history of what happened to each record. It presents data; it does not interrogate it.

The bolt-on approach also struggles with control. Who is responsible when the AI suggests a wrong entry? In a bolt-on, the AI is a separate add-on with its own permissions, often managed by a different team. In Kinnow, the agent's actions are logged in the same audit trail as every human action, under the same sign-off steps, with the same compliance controls.

The rootstock matters

Kinnow's bet is that the rootstock determines the fruit. An ERP built for recording will always produce recording. An ERP built for reasoning will produce insight, automation and better decisions - because the intelligence is not grafted on top; it grows from the root.

The question for any business evaluating an ERP today is not "does it have AI features?" Every vendor will say yes. The question is: where does the intelligence live? If it sits on top, it will always be limited by the root underneath.