The work between an AI answer and a business result

Technology leaders at large financial institutions often put the build-versus-buy question this way: we already built most of this in-house.

Take that work seriously. The team knows its systems, has navigated its security review, and already owns useful integrations. A vendor who dismisses it as a chatbot has misunderstood the buyer.

The next question is concrete: what responsibility can that system carry today, and what still depends on your engineers?

Start from the system you have

A retrieval service over joined records is one possible starting point. A durable agent runtime with tools, permissions, scheduled work, and a business-facing application is another. Calling both of them an internal build hides most of the decision.

The available components have also changed. Claude Managed Agents, currently in beta, supplies a configurable harness, stateful sessions, tools, and scheduled execution. Its managed service has deployment and retention constraints to review. It is substantially more than a bare model API.

Enterprise platforms also assist implementation. Palantir AI FDE can operate Foundry, build connections and pipelines, and propose Ontology and code changes for review. Existing platforms deserve evaluation on those actual capabilities.

An internal team can build proactive execution and company-specific learning. There is no architectural law that prevents it.

Compare one responsibility

Choose a recurring problem the business owns: reducing avoidable onboarding delays, for example. Give both approaches the same systems, data limits, success measure, and approval rules.

Then inspect the work in five parts.

Understanding the problem. Can the system connect the relevant records and explain missing or conflicting evidence? Which mappings were already available, and which required new work?

Preparing the response. Does it reuse an existing capability, adapt a workflow, or require a new specialist? Show what a person changed before activation. A useful response may be a question or a recommendation to wait.

Carrying authorized work forward. Show the permitted actions, standing authority, required approvals, and result of each write. Include a failed integration or expired permission. A plan that works only on the happy path leaves operating work with the customer.

Measuring the result. Completing an onboarding task is different from shortening ramp. The workflow needs a baseline, an outcome source, a time window, and an owner for the later check.

Keeping the learning useful. A human edit records a judgment. An observed outcome records what followed. Neither should silently become a rule for every team. Test whether a scoped lesson helps a later applicable case without degrading unrelated work.

These are shared evaluation criteria. They are not claims that only Nodes can meet them.

Run the comparison against the same starting line

Suppose an operations leader wants new hires to reach an agreed readiness milestone sooner. This is an illustrative evaluation, separate from the insurance production evidence. The organization already has an employee directory, training records, and a reporting feed. Some useful integrations exist. A manager still reconciles exceptions in a spreadsheet.

Before either team starts, write down what counts as readiness. Course completion may be one requirement, while licensing, manager sign-off, or access to necessary systems may be others. A team that optimizes the easiest available field could deliver a convincing demonstration of the wrong process.

Give both options the same permitted records and the same authority. If one gets write access while the other only receives a static export, the resulting comparison will mostly measure that difference. Record unavailable evidence and any work a customer must complete before testing can begin.

Credit existing assets. An internal integration that already works should not be rebuilt simply to make the contest symmetrical. Equally, a vendor should identify which parts of its demonstration were prepared for this customer and which are established product capabilities. The buyer wants the cost of moving forward from its actual position.

Use a shared effort ledger that names a person responsible for each entry:

| Work to record | Evidence to retain | | --- | --- | | Understand the process | Definitions resolved, missing information, and business-owner review time. | | Connect the records | Existing components reused, new mappings, access requests, and engineering time. | | Prepare authorized actions | Proposed workflow, approval boundaries, changes requested, and test results. | | Operate an exception | Who noticed the issue, who repaired it, and which work had to wait. | | Check the business result | Outcome source, measurement date, review effort, and unresolved limitations. |

Keep elapsed time and human effort separate. A permission request can spend several days in a queue without consuming several days of engineering. A fast demonstration can require intensive preparation that its audience never sees. Both measures matter, but they answer different purchasing questions.

Make the second task reveal what was reused

Once the first workflow passes its agreed checks, introduce a nearby problem that was not encoded in the demonstration. For this example, a different team may complete training promptly but wait for system access. The second task should preserve the same authorization limits while changing the likely explanation and useful response.

Ask the system to show its sources, available capabilities, and remaining gaps. It might reuse the identity mapping and task tracker while needing a new approved operation for access requests. It might discover that the evidence cannot support a useful recommendation yet. Either response is more informative than silently substituting an already prepared onboarding sequence.

Compare the additional work in the same ledger. Did the customer repeat its definitions? Did engineers rebuild a connector? Could the business owner inspect and edit the proposed change? Reuse becomes a purchasing advantage when it reduces specific work without carrying an inappropriate assumption into the new task.

Keep a record of rejected suggestions too. A reused component can save effort even when the right response is to leave an existing process unchanged.

The test should also include an ordinary interruption. Revoke a test permission or make a dependent service unavailable. Observe whether the system exposes the dependency, retains the approved plan, and tells the owner what remains unresolved. Do this in an authorized test environment with effects constrained to the agreed scope.

Write the acceptance decision in terms the operating owner can verify. A complete run might require an approved task to appear in the destination system with the correct owner, while the overall business outcome remains pending. Neither a fluent explanation nor a completed API call resolves a missing outcome report.

This exercise can favor an internal build, an existing platform, Nodes, or a combination. An internal system may already satisfy the responsibility with little additional work. A vendor may remove a substantial maintenance burden. Preserve those findings rather than forcing a winner across every possible future use case.

The Nodes case to test

Nodes is building a proactive intelligence layer around persistent company context and bounded AI work. The aim is to retain the evidence, judgments, decisions, and results while reusing tested capabilities for the next responsibility.

The public production evidence is narrower: candidate evaluation at one Fortune 500 insurance carrier, with separately reported outcomes and retrospective research. The evidence register records those results and their limits. The Decision Traces methodology supports the research discussion; it does not establish that the complete autonomous enterprise loop has shipped.

In a product walkthrough, ask which parts of the proposed responsibility work today, which require implementation, and which remain product direction. That includes capability creation, cross-system execution, recovery, and automated outcome learning.

The value of buying Nodes must appear in that demonstration and the agreed scope. An architectural diagram cannot establish lower implementation effort by itself.

Count the work after launch

Compare the license and infrastructure cost with implementation, retained engineering, business review, maintenance, and transition work. Avoid a comparison that charges internal engineering to one option while ignoring deployment labor in the other.

Who repairs a changed API? Who evaluates a replacement model? Who reconciles a write whose response was lost? Who checks the business outcome when it arrives a quarter later?

Ask what a second workflow reuses from the first. Reuse should be visible in accepted mappings, tested tools, appropriate context, and saved implementation effort. Customer-specific facts and confidential lessons remain inside their permission boundary.

Owning data also differs from owning an indefinite license to the runtime. Agree which intelligence and artifacts remain usable after exit, in what form, and with what replacement work.

The next step

Bring the team that built the current system to the product walkthrough. No historical dataset is required to understand the product. A Decision Replay is a separate way to test a suitable historical decision.

Decide which work the business wants its engineers to keep doing, then choose the approach that demonstrably takes responsibility for the rest.

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.