Intelligence Has Arrived. Judgment is Still Being Built.

Enterprise outcome = (context + intelligence) × trust, and what happens when you use it to fulfill the promise of AI.

Shipping an AI agent comes with its own small bureaucracy that we didn’t anticipate. With shipments starting to resemble the next ERP, the situation is comparable. ERPs hold data. This layer will hold the story behind the data. The firm’s response to events, management priorities, and strengths are the main components that underpin the firm’s workflows.

With that in mind, this is an incomplete list of components in workflows that were derived from modern context AI layers, which didn’t exist in past software of past eras:

A context AI.

A policy layer.

A permissions model.

An eval suite.

A monitoring system that tracks sequences of actions as opposed to single actions.

A human approval gate for anything irreversible.

And a security posture for a class of attack that didn’t exist three years ago.

All of those examples are reasons why a model can safely and securely interact with the real world.

We used to think that making a model useful for a given application would be the hard part of this endeavor. Fortunately, the labs solved that for us. The hard part was the bureaucracy that came with shipping the agent once our customers started integrating it into the workflows they were personally liable for with individual licenses and co-pilots.

We didn’t work with engineers or developers who take pride in fixing things that are broken/not working out of the box. I worked with a non-technical audience - Asset managers, controllers, asset teams, and capital allocators. Folks who wanted to ask a clear question, get a clear answer, and go back to their business. They weren’t interested in the prompting technique, reading a trace, or writing a Substack after fixing what was broken. They wanted something they could pass on to the next person in the approval chain and defend against pushback on the bottom line in the meeting.

You can get away with a lot less in a technical organization because the customer normally closes the gap between a crude output and a useful result. A nontechnical enterprise hands you that whole stretch. That’s why I see the largest opportunity in building fully autonomous enterprises.

Getting back from that detour of a thought:

The requests all seemed to be pretty simple.

“Please send the Monday report.”

“What’s going on with occupancy in Dallas?”

“Please convert the data room to an Investment Committee memo.”

These requests would also include steps to many more decisions that are usually absent from the prompt. Which rent roll is the latest? Which entity definition is the correct one? Is the variance significant enough to report? Who has access to the underlying lease? Does the report cover the underlying data in the source system? If a number is incorrect, should the system correct it, stop, or ask someone?

The outputs might look great to someone outside the org (to an FDE or a person without deep context) or read like a good draft for internal folks. But that does not mean they are actually ready to be used in the task.

I have been working on a solution to this problem at Leni. Institutional Finance and real estate is a perfect vertical to build on because, compared to many other industries, it is quite unforgiving. Data is very much trapped in silos. A single workflow can span across the various teams, including property management, ownership, financing, and investment. A report may look completely correct and be ready to consume, but may have a huge underlying error due to a single mapping, date, or calculation.

This has contributed to the development of our simple internal equation:

\(\text{Enterprise outcome} = (\text{Context} + \text{Intelligence}) \times \text{Trust}\)

This is often abbreviated to ‘context, intelligence, and trust.’ The multiplier (trust) is they key to non technical enterprise adoption. If a result can’t be verified or validated, it’s of little value to the business, no matter how articulate it is.

The foundational models have developed, and continue to develop, at a rapid pace, and we benefit from that daily. But the quality/intelligence of models was just one piece of the puzzle, and did little to address that chasm. Which I believe is because most enterprises just work but they thierself cannot fully articulate the entire system or how (in short most enterprise, don’t know how they work), not many people in these organisations have questioned why a process is followed, and none of this was ever available for any model to learn from in the first place.

What surprised a lot of us was how our deployments encapsulated a lot of the firm for the first time. To what extent here means fully occupied, or to what extent represents a suspicious amount of occupancy, and warrants a phone call. Or what feedback meant when a draft was sent back in a previous quarter. After a couple of years, that feedback is worth more than the workflows it integrates and today’s defined process, and answers a question that most firms, to this point, have not been able to address. Where is that information, an who has power over it? I will come back to that, again, later in this piece.

Nothing in the Context Window Is Privileged

Early on, we assumed the answer was to connect more systems. Give the model the rent roll, the general ledger, the lease folder, and the prior reports. Retrieve the relevant information. Ask it to write.

That helped, but it did not get us to a dependable result.

It’s possible to be a new analyst at the firm and be given unrestricted access to every drive and folder in the company, and still not understand how the company as a whole builds the Q4 report for the CFO. One could be completely unaware that one of the operators has a completely different understanding of occupancy than the others, that one of the investors prefers the deal narrative to the tables, or even that a variance isn’t of any concern unless it relates to concessions. Much of this is only known when the draft has failed or is subpar. The person who got this result already might hates AI says it would have been faster if I have done that my self without AI. That’s where the adoption is failed or friction builds. This is similar to what we used to see in SDLC (software development life cycle) every dev likes to code the feature more than checking someone's else’s code. According to them, that's faster/more efficient.

That barrier is context.

An average retrieval system takes documents, makes a copy and index, splits them into chunks, and returns the fragments that are likely to be correct. That can be useful. But it is super valuable when the file has been updated, access has been restricted, or when the connective logic between documents is needed to address the inquiry.

To solve for the right context augmentation, instead of a retrieval system, we designed a connector-routed knowledge graph. This system connects a document to a workflow and to other documents within the system while maintaining its meaning. When an agent needs a certain answer, the system does this in real time and directly from the document based on the agent’s access permissions.

During an internal benchmark, comparing the base model only, top-k retrieval precision improved from an approximate 72% to 92%. The median retrieval latency also improved by approximately 42%. The number of context tokens also dropped by nearly 61%. Retrievals that would Stale or violate access permissions dropped from roughly 41 in 1000 retrievals to less than 1 in 1000.

Using this RKG technique, context moved from being an output shaping prompt to live, access controlled, and work adapted infrastructure.

A Frontier Model Should Not Do Every Job

Agent models usually consist of a single reasoning loop described in a similar way by each of the authors. Each model interprets the input, plans the task, invokes the tools, reads the results, writes the output, and evaluates the results.

This interpretation is fine, but it is pretty strange to adopt this picture for a production system as it provides subpar results and a harness that loops through to get this right becomes expensive quite quickly.

The requests our clients made for task automation showed us these tasks contain many different tasks. Each model may need to synthesize a long document, calculate a number, parse a response from a tool, determine which system to call, validate an output with the corresponding source, and signal the corresponding error. These are all different tasks and therefore must be treated differently.

To achieve this goal, we partitioned the workflow into roles that can be observed and validated independently.

This is why we trained small specialists with our own traces of what good looks like for various portions of the loop. One of them checks the differences between the cells of the spreadsheet. One of them challenges prompts that were built upon incorrect premises. One of them transforms the tool output that is in an unstructured form to a typed artifact. One of them directs tasks to the model or tool that is appropriate.

A small model is not better than a large one in every case. However, because a small model is highly specialized, we may be more certain for highly constrained tasks that we can more safely check and train the model.

The distinction emerged in our evaluations. With respect to SpreadsheetBench Verified, the entire system, using a complete self-same foundational base-model configuration, showed a significant leap from 80.25% to 91.25% over 400 tasks. On BullshitBench v2, it showed an increase in the correct rejection of faulty premises of 7 to 10 points. On GAIA validation, pass@1 improved from around 60% to 75.2% over 165 tasks.

There was no change to the base model. The improvement came from placing more thoughtful context around the base model, more thoughtful routing, and an external validation of the result.

There Is No Root but a Loop of Trust

When a person wants to know if they can trust the result provided by an AI, they are not asking for a philosophical explanation. What they want to know, in a case such as this, is for example:

- Can I send this to the user? / Can I show this to the user?

- From where was this number pulled?

- What changed this time compared to the last month?

- What checks were made by the system?

- What happens when the system is not confident about the result?

When we were asked these types of questions, we knew we had to give the systems the capability to address these questions. In world out side of software there is no QA team that will catch the bug and devs are only there to produce and it's acceptable for the producers to make mistakes or errors. Outside world is brutal is analyst, director, VP makes a mistake. It may cost them their job. I remember one client once said to me “I'm too afraid to show this to CEO, till i am sure, as I have seen him fire people who have presented incorrect numbers”

Something is wrong even if a report seems to address all of the questions if there was a failed mapping of an entity. A workbook can have the correct formula, but in the wrong cell. A summary can refer to a document but in fact cite an older version. Even though all steps of a process seem to be individually allowed, an agent can execute the process to achieve an unintended result.

The problems described here can not be fixed with a single system prompt. These problems require system checks and beyond.

Intentionally, we kept our verification loop plain: Execute, Observe, Compare, Correct.

The executor does the task.

The observer reads and structures the result.

Compared to the correct system, ground truth is checked. Based on the task, ground truth can be the a recalculator, a source system, a policy, a confirmed template, a decision, or a standard.

Depending on the task, disparity can be addressed by going to a person who will revise it.

This is possible for systems such as spreadsheets where the comparison can be deterministic. For example, an observer can recheck the workbook and see which cells are different. For diligence, the system should do an epistemic triage to address a false premise before writing around it, and for reporting, the system should check for freshness, completeness, and Reconciliation to the record-keeping system.

Trust is not a confidence score next to an answer. Enterprises don't work that way. The bar for productionising AI is high. Humans tripple check things before presenting to investors - a confidence score below 100 is not production ready. Trust for non-technical enterprises is a history of what was verified, what it was verified with, and what remaining doubts exist.

A Sequence of Reasonable Steps Can Add Up to a Bad One

At first, an individual action of a tool doesn’t seem dangerous. Read a document. Query a record. Generate a report. Send it to an email you have been instructed about.

Doing some of those steps out of order or sending it to the wrong location could result in a leak or the system approving a request without a formal approval.

Permissons to the tools are important, but they do not account for the chain of events. Most of the problems that occur in an enterprise comes from the chain of events.

Policy must be placed outside of the model. The model must be capable of understanding the request to make the appropriate plan. The model should not have the capability to determine for itself the information it is allowed to make public. The same goes for the information it is allowed to modify or the information it is allowed to send.

As processes grow in length, we’ve learned to tread lightly. What may work seamlessly in three steps may be problematic in fifteen. The further we go, the more context we lose, and the more small mistakes add up. At some point, the original goal may be completely concealed by a long series of tool commands.

The best way to go about this is to gradually allow autonomy. For now, only allow a bounded workflow with designated source systems and outputs, evident approvers, and test sets. Only allow more autonomy when the system proves to be a good citizen of that environment.

Having the capacity to do something and being allowed to do something are not the same. While the former may be more general, the latter is more specific and needs to be clear.

Production Quality Comes From Feedback-Based Loops

Better base models will integrate some of the infrastructure that we have now. More things will become standardized, including tool use, planning, and some reliability. That’s positive. It shows us what is left with the enterprise.

Every accepted report, modified calculation, rejected draft, or settled exception conveys what the enterprise is like. There are decision traces, and over time, they will make briefs and models better.

Here is how the loop works:

1. A context layer provides up-to-date information, definitions, authorizations, and pertinent precedents.

2. The correct model and/or expert accomplish the task.

3. Verification assesses the result against the truth and directs exceptions to the appropriate person.

4. Both the accepted result and the adjustment are structured forms of feedback for the subsequent task.

This is what we mean when we say that enterprises should have their own AI. The benefit of having your own AI is not that you are tied to a foundation-model provider. Being able to document the context, the decisions, the controls, and the evidence of the organization helps the enterprise to enhance every next model and to make it better than the previous one.

Enterprise teams require an AI that can produce all the work in full, justify the work, determine what still requires expert work, and adapt to the organization's standards, eliminating the need for the tech team to modify the workflow every few months.

How the Equation Shows Up: Fulfilling the AI promise

What Remains When the Models Improve

A new model may streamline existing elements of a stack. But considering the current state of inference-based models, given that they are pre-trained and then retrained with every new model, they are ultimately generating output tokens based on the past; it is impossible for them to include an important attribute of enterprises - constant, nuanced evolution and human decision-making that generates alpha. Most organizations and enterprises are living and breathing, and they evolve and manage change on a daily basis, and most importantly, they adapt, and do so very quickly. This is a very important aspect in order to remain competitive. Inference-based models today are great at mimicking intelligence, but this ever-evolving context of enterprise should and will remain outside of the models to support pre-trained intelligence. In addition, enterprise-oriented retraining may be not feasible for a 6 trillion parameters frontier lab model.

The same applies to controls. Permission boundaries, independent checks, approvals, and sequence monitoring do not suddenly vanish just because a model improves prose.

What about the feedback? Accepted reports, amended calculations, and rejected drafts indicate to the system the manner in which the work is to be done in future. This knowledge should be retained by the company, even if there are model changes. Also, more often than not, these nuances are too small (so useless for masses) to be part of a parametric memory of a large model

While a competent agent can provide a plausible answer, an enterprise system must provide the capability to create work that can be checked, repeated, and improved by people.

What is brought together by this over a number of years is far greater than automation. This is what institutional memory actually is. This is the actual definition of occupancy for this firm. This is what accounts matter, and what adjustments are significant. This is which number is wrong, and which person has to be called. This is all of the changes to be made that never made it into the process document. CRM and ERP systems became the backbone companies could not pull out without breaking themselves. This is the place where operational knowledge is stored. This is the place that doesn’t just record the past. It is the place that records the future.

Instead of making a decision, most companies have been slowly drifting towards making that decision. Systems that were never intentionally chosen are now filled with workflows, judgments, and agent behaviors that are tailored to your business after a year of slumber. The only way to sync the integration that has been built, is to export all of the workflows within the system and the data that has been processed. It is closer to a one way door with a system that has been chosen in a way, than a migration of your data.

What is obvious and what is worth asking is, from what you have, what processes do you need to be in the game and what processes do you need to win? For processes that you need to be in the game, use whatever platform is easiest. Decide processes that you need to win on elsewhere. The choice, what, where, and when, should be documented and kept somewhere that you have control of. Do this to ensure the next model release makes your system better rather than resetting it. Firms will change models more than once in the next decade. What they should not have to change is really what their AI knows about how they work.

Until next time,

Arunabh Dastidar