The Intercompany Operating System

Enterprises have invested heavily in software and AI to improve the work inside their organizations. Yet many processes depend on commitments made with customers, suppliers, logistics providers, lenders, and other independent businesses.

An order can be accurate in one system and outdated in another. An invoice may reflect an amendment that the receiving team cannot find. A shipment can arrive while the evidence needed to approve payment remains disconnected from the transaction.

The opportunity is to bring the discipline of enterprise operations to the space between companies: shared business context, approved authority, coordinated action, and evidence of what happened.

NeurWare is building an Intercompany Operating System--a coordination layer designed to help businesses see the relationship, govern its commitments, and orchestrate its next steps.

This January 2026 vision paper sets out what we are building. It describes the intended architecture, the practical starting point, and the broader ecosystem we aim to enable. The capabilities described are a development direction; they are not a statement that the full platform or ecosystem is available today.

The coordination problem

Within an enterprise, systems of record provide a common reference for transactions, identities, permissions, and approvals. Even there, integration and exceptions remain difficult. Across company boundaries, the challenge grows because each participant operates its own systems and retains responsibility for its own decisions.

Three questions recur:

• State: Do the parties have a consistent understanding of the order, changes, delivery, acceptance, invoice, and payment?
• Authority: Who may approve a change, share information, make a commitment, or release a payment?
• Execution: How does an approved action move through the participating systems, and what happens when a step fails?

EDI, APIs, portals, and integration platforms are valuable infrastructure. They move information and support existing commerce. A coordination layer builds on those investments by connecting individual messages to the relationship and the rules that give them meaning.

A transmitted message is evidence of communication. The resulting business state still needs to be established: whether it was accepted, which version applies, and what the parties have authorized next.

See: an intercompany Control Tower

The practical starting point is the commerce already taking place.

NeurWare’s proposed Control Tower connects authorized transaction evidence across orders, acknowledgments, amendments, shipments, receipts, invoices, and payments. It gives operations and finance teams a lifecycle view rather than a series of disconnected documents.

That view can help reveal stalled processes, conflicting quantities, missing approvals, recurring exceptions, and opportunities that warrant investigation. Each finding needs enough context for a person to understand the issue and decide how to act.

Observation also requires uncertainty to remain visible. A missing receipt message does not prove that goods never arrived. A price variance may indicate an unrecorded amendment. The Control Tower should distinguish confirmed facts, disputed records, and missing evidence.

Early value comes from helping people investigate and resolve existing problems. Positive returns depend on transaction coverage, usable data, implementation cost, and the organization’s ability to act on the findings.

Govern: connect commitments to approved authority

Business history explains what happened. Approved agreements and policies establish what is permitted.

An Executable Agreement represents reviewed commercial rules in a form that software can evaluate. It should retain traceability to the governing source, applicable version, effective date, responsible parties, and approval history.

Some rules are suitable for deterministic checks: permitted quantities, price tolerances, delivery windows, required evidence, approval thresholds, and delegated limits. Ambiguous provisions and judgment-dependent exceptions require authorized review.

The legal agreement remains authoritative. Translating terms into executable rules requires approval; a pattern inferred from transactions is not automatically a binding obligation.

Authority must be explicit for people and agents. Which company does the actor represent? What information may it access? Can it recommend, draft, approve, or commit? What limits apply? When does another person or organization need to consent?

These controls must be enforced at the action boundary. A dashboard warning is insufficient if a separate integration can bypass it and write directly to the receiving system.

Orchestrate: coordinate the next business action

Orchestration connects context and authority to work across participating systems.

For an invoice discrepancy, a workflow could assemble the current order, approved amendments, receipt evidence, applicable terms, and payment status. An agent could explain the conflict and prepare a response. An authorized employee could approve that response before it is transmitted.

Over time, a business may delegate selected routine actions within enforced boundaries. The appropriate level depends on the action, trading partner, evidence, risk, and regulatory context.

A company can retain approval for sensitive decisions indefinitely. Increasing autonomy is a business choice supported by evidence, rather than an automatic destination.

Revocation, failure handling, and recovery need to be designed into the workflow. A payment or shipment may require a compensating action; it cannot always be undone by reversing a software record.

Making intercompany commerce agent-ready

NeurWare is building the business context and authority layer that agents need to participate in autonomous commerce. Connected transaction evidence helps an agent understand what was agreed, what has happened, and what remains unresolved. Executable agreements and explicit permissions define what it may do, for whom, and within which limits.

Governed orchestration then coordinates authorized actions across companies, applications, and service partners. When evidence is incomplete, terms conflict, or an action exceeds delegated authority, the workflow routes the decision to an authorized person. Businesses can expand autonomy as results justify it, while retaining control, traceability, and the ability to revoke authority.

See establishes context. Govern establishes authority. Orchestrate enables controlled action.

A shared coordination layer above existing systems

The proposed architecture sits above existing enterprise systems. ERP applications remain important systems of record, and partners retain control over their internal information.

A shared record does not mean unrestricted access to both companies’ data. Selective disclosure, purpose-specific permissions, and commercial confidentiality are fundamental requirements.

Nor does it mean that conflicting records disappear. The system needs to make disagreement understandable, preserve both accounts, and identify the decision and authority needed to resolve it.

Governance and observability across the workflow

A common governance service can make controls consistent across connected workflows while allowing each business to define its own approved policies and delegated authority.

The design combines a platform baseline--identity checks, access controls, audit logging, and data boundaries--with organizational policies and workflow-specific requirements. Sector and jurisdictional obligations require explicit implementation and validation; connecting a service does not establish universal compliance.

Observability should explain both the business process and the agent activity: the evidence used, rule versions checked, approvals granted, actions attempted, external-system responses, exceptions raised, and costs incurred.

An audit trail supports accountability. Its completeness, retention, integrity, and suitability for a particular legal or regulatory purpose must be established for that deployment.

Purpose-built agents, coordinated by business context

The platform vision includes agents with distinct responsibilities that cooperate within approved workflows.

A lender remains responsible for underwriting and financing terms. Authorized payment providers and connected systems retain their respective execution responsibilities. The coordination layer makes evidence and approvals available to those participants.

A practical path: establish, prove, expand

The platform direction develops through three stages.

Establish the coordination layer. Begin with a defined trading relationship and transaction lifecycle. Connect existing evidence, make exceptions visible, and introduce approved rules where the evidence supports them.

Prove value in a focused workflow. Choose a problem with a measurable baseline: time spent investigating discrepancies, approval delays, missed agreed discounts, or recurring transaction conflicts. Measure implementation and ongoing operating costs alongside outcomes.

Expand through an ecosystem. Once the underlying context, permissions, and workflows are dependable, expose appropriate services and interfaces for additional applications and partners.

This sequence supports incremental adoption. It does not require every counterparty to replace its systems or accept the same level of agent autonomy at the outset.

Applications and orchestrations: two complementary layers

An Intercompany Business Application provides a specific capability that works across company relationships. It may help a user understand inventory, assess counterparty reliability, discover financing options, account for sustainability evidence, or forecast cash flow. It can deliver intelligence, support a decision, or perform an authorized task.

An Intercompany Business Workflow or Orchestration coordinates a business outcome across participants. It connects events, evidence, applications, services, approvals, and actions over time. It determines what happens next, who may act, what must be verified, and how exceptions are resolved.

Applications can participate in many orchestrations. An orchestration can combine several applications with human decisions and external services. The Control Tower makes their progress visible; approved agreements and permissions govern their actions.

Partners become participants in the workflow

The ecosystem we are building toward includes banks, insurers, purchasing-card (PCard) issuers, legal service providers, and other specialists as active participants in intercompany workflows.

A bank could receive an approved evidence package and return a financing decision. An insurer could evaluate a covered event and request additional evidence. A PCard issuer could support an approved payment option. A legal service provider could review an agreement or help resolve a contractual exception.

Participation requires an agreed role, appropriate access, and explicit responsibility. Joining a workflow does not grant unrestricted access to a customer’s data or authority to act on another company’s behalf.

For example, an invoice-financing orchestration could connect buyer acceptance, supplier consent, a financing-discovery application, bank underwriting, legal review where needed, and an authorized payment service. NeurWare’s intended role is to coordinate the evidence, permissions, decisions, and handoffs--not to replace those participants’ expertise or accountability.

A new class of intercompany applications

A permissioned coordination layer could support applications that work across relationships rather than within a single company’s software estate.

These are application directions, rather than claims that every capability is available today. Their value depends on partner participation, data quality, integration, permissions, domain-specific requirements, and demonstrated outcomes.

Shared transaction evidence alone does not establish an accurate credit score, verify emissions, create a carbon credit, or guarantee financing. Each application adds its own expertise, controls, and validation.

Developer and marketplace foundations

The ecosystem vision includes interfaces for permissioned trade state, approved agreement rules, orchestration services, and transaction events. A testing environment could let developers exercise workflows and failure cases before requesting production access.

A common interface can reduce repeated integration work. It does not remove the need to map partner systems, define access, review commercial terms, and validate each deployment.

Marketplace discovery could help customers find financing, logistics, compliance, and analytics services. Activation should follow the approvals, due diligence, data permissions, and technical checks relevant to that service.

Outcome transparency matters alongside discovery. Customers need to understand what a service delivered, what it cost, and which results are attributable to it.

Opt-in intelligence: “there is an app for that”

Alongside workflows, we envision partners and developers building intelligence products and applications against data that participants have explicitly permitted for those purposes.

The aim is a growing ecosystem: “there is an app for that” for intercompany inventory visibility, financing discovery, counterparty insights, cash-flow planning, and other business needs.

This requires two distinct data paths.

Permissioned shared data supports a particular relationship, application, or workflow. A participant authorizes defined information to be used by specified recipients for an agreed purpose. Access to one transaction does not authorize reuse across the ecosystem.

Opt-in aggregated and anonymized data could support broader intelligence and applications where contributing organizations expressly agree. Participation in the platform or a workflow should not automatically enroll a business in these uses.

Participants should be able to understand what they are opting into: which information contributes, which products or recipients may use it, how confidentiality is protected, how long it is retained, and what withdrawal changes. Treatment of previously created aggregate outputs needs to be clear in advance.

Anonymization requires more than removing company names. Small cohorts, unusual transactions, and combinations of data can expose identities or commercially sensitive details. Aggregation thresholds, disclosure checks, access limits, and re-identification testing need to be appropriate to the proposed use.

Data contributors retain control through the permissions and agreements they approve. Applications receive the access they need for their authorized purpose; they do not inherit blanket rights to the network’s records.

This is how intelligence and applications can develop alongside orchestration: permissioned data supports the specific work, and separately authorized ecosystem data supports new insights. The business value and the privacy controls must be demonstrated together.

Measure outcomes before promising transformation

The commercial case should begin with the customer’s operating baseline and a clearly defined workflow.

Useful measures include investigation time, exception recurrence, resolution time, approval effort, false positives, missed exceptions, unauthorized-action attempts, and the reliability of connected evidence.

Labor capacity, operating expense, released working capital, and financing costs are different measures. An evaluation should explain which changed, how the change was measured, and what costs were required to achieve it.

NeurWare’s initial proposition is to improve the visibility and coordination of existing commerce while creating the context and authority needed for trusted orchestration. Customer results must establish the pace and extent of expansion.

The vision: make intercompany intelligent

The space between businesses is an operating environment in its own right. It contains commitments, evidence, decisions, permissions, and economic opportunities.

The Intercompany Operating System we are building is intended to bring those elements together: a Control Tower to See, approved commercial boundaries to Govern, and coordinated workflows to Orchestrate.

The long-term opportunity is a new class of applications and business orchestrations built on permissioned, governed relationships. The practical starting point is the work companies already need to understand and resolve today.

See it. Govern it. Orchestrate it. Make Intercompany Intelligent.