Building an AI-Native Supply Chain Platform: Our Starting Point

The next generation of supply chain software will need to do more than make information accessible. It will need to understand operational context and increasingly participate in the work itself. At KONKORD, we are approaching this transition from an existing supply chain software foundation — and from a simple conviction: reliable AI execution starts with understanding how the business actually works.

Starting with the Work, Not the AI

When we started rethinking the next generation of KONKORD, we did not begin by asking which AI agents we could build.

We began with a more fundamental question: What would it take for software to assume a meaningful share of the operational work involved in managing global supply chains?

The distinction matters.

Recent advances in AI make it possible to interpret documents, understand natural language, reason about complex situations, and interact with software tools in ways that were previously difficult to automate.

These capabilities open up substantial opportunities. But they do not automatically translate into reliable business execution.

Understanding an email is not the same as resolving the operational issue it describes. Identifying a delayed shipment is not the same as coordinating an appropriate response. Extracting quantities from a supplier document is not the same as correctly updating orders, shipments, and related operational records.

Between interpreting information and completing a business task lies a layer of operational complexity that AI alone does not eliminate.

That is where we believe the next generation of enterprise software must focus.

Our ambition is to build an AI-native operational platform for global supply chains. Our starting point is an existing software application, a structured understanding of supply chain processes, and the recognition that meaningful automation requires much more than intelligent models.

Why We Chose Supply Chain Operations

Global supply chains are a demanding environment for operational software.

A single shipment can involve manufacturers, suppliers, freight forwarders, carriers, warehouses, customs authorities, and customers. Each participant may work with different systems, data structures, documents, and communication channels.

Even when individual organizations have sophisticated enterprise applications, the overall process often remains fragmented.

An import manager might receive purchase orders through an ERP system, shipping updates from a logistics provider, container events from a tracking service, packing lists by email, and customer requirements through an entirely different application.

The challenge is not simply accessing these pieces of information. It is understanding how they relate and determining what needs to happen next.

A change in shipment arrival time may affect several orders. A supplier may ship only part of the ordered quantity. A container may hold products from multiple purchase orders, while the remaining quantities are assigned to later shipments.

Each event creates operational consequences that extend beyond the system in which it first becomes visible.

Employees bridge these gaps every day. They interpret information, reconcile inconsistencies, contact external parties, update records, and coordinate the next steps.

Much of this work exists between applications rather than within them.

The logistics industry has made important progress toward standardization and digital integration. Organizations such as the Digital Container Shipping Association (DCSA) are working to address fragmentation in shipping data, processes, and technology through common standards and interoperability. Yet improving information exchange is not the same as completing the operational activities that information triggers.

This distinction defines the opportunity we see.

We are not primarily interested in building another interface that presents supply chain information more elegantly.

We want to explore how software can progressively take on the work required to keep operations moving.

Our Starting Point: An Existing Operational Foundation

KONKORD did not begin as an AI-native platform.

Our existing software foundation was developed around the practical requirements of managing international shipments: organizing shipment information, tracking containers, and supporting the people responsible for coordinating supply chain activities.

This starting point matters because operational execution depends on more than individual pieces of information.

A shipment is not simply a record containing a departure date, an arrival date, and a tracking number.

It may be connected to containers, cargo, orders, documents, events, and the activities required to move goods from one location to another.

Those relationships shape how operational work is performed.

An order may be fulfilled through several shipments. One shipment may contain cargo associated with multiple orders. Goods that were expected to ship together may be divided because a supplier cannot deliver the complete quantity on time.

These situations require a system to distinguish between what was ordered, what has been assigned to a shipment, what has physically moved, and what remains outstanding.

This is why our product development has placed considerable emphasis on modeling operational business objects and the relationships between them.

Our work with orders, order lines, shipments, containers, and cargo reflects the need to represent these relationships explicitly. The implementation of this broader operational model is part of the foundation we are developing, not a claim that every capability is already available in the current product.

Moving toward AI-native software is therefore not simply a matter of adding a language model to an existing interface.

A conventional application can provide users with structured information and tools for managing it.

An AI-native operational platform must go further. It needs to connect intelligent interpretation with the business context, rules, and permissions required to perform meaningful actions.

Our existing software provides a starting point for that development. It does not mean the architectural transition is already complete.

Some capabilities can build on established components. Others may require different approaches to how workflows, decisions, and execution are designed.

We see this as an opportunity to rethink the role of the application itself.

The Missing Link Between AI and Business Context

Modern AI models are increasingly capable of interpreting unstructured information.

They can read emails, analyze documents, recognize relevant entities, and suggest actions based on the content they receive.

But business execution requires more than understanding the words in a document.

Consider a supplier message stating that 800 units are ready for shipment, although the original purchase order contained 1,200 units.

A language model may correctly identify the discrepancy.

To handle the situation operationally, however, the system must understand what those quantities represent.

Which purchase order is involved? Which order lines are affected? Have any quantities already been assigned to existing shipments? Does the new packing list describe a partial shipment, a replacement shipment, or a correction to previously supplied information?

These distinctions cannot be resolved through language interpretation alone.

They require access to structured business context and an understanding of the relationships between the relevant objects.

In our domain, that includes orders, order lines, shipments, containers, cargo, and the quantities associated with them.

It also includes the business rules that govern how those objects may be created, connected, or modified.

The relationships are particularly important.

If 800 of 1,200 ordered units are assigned to a shipment, the system must preserve the distinction between the assigned and remaining quantities. If the supplier later announces another delivery, that information needs to be associated with the correct outstanding order quantity.

A plausible AI-generated answer is not sufficient. The resulting business records must remain consistent.

This is the difference between interpreting operational information and acting correctly on it.

It also explains why we consider domain modeling a central part of AI-native software development.

A model of the business does not make AI infallible. It does not solve problems caused by missing data, inconsistent information, or ambiguous supplier communications.

But it provides a structured foundation against which proposed actions can be evaluated.

AI can interpret what a supplier says. The operational system must understand what that means for the business.

From Understanding Documents to Executing Work

A practical example illustrates how these ideas come together.

Imagine a European importer that purchases electronic components from a supplier in China.

The importer has placed an order for 1,200 units across several product lines. The purchase order and its individual lines are recorded in the company's business system.

A few weeks later, the supplier sends an email confirming that only part of the order is ready for shipment. An attached packing list details the 800 units that have been packed, including product identifiers, quantities, and packaging information.

The remaining units will follow later.

In a traditional workflow, an import manager must review the message, compare the packing list with the original order, determine which quantities are ready, and associate those quantities with the appropriate shipment.

If discrepancies appear, the manager must contact the supplier. The relevant business records must then be updated without losing track of the outstanding quantities.

This is a familiar type of operational work. It is also a useful example of where AI could make a meaningful difference.

A future AI-native workflow might begin by interpreting the supplier's email and attached packing list.

The system could identify the relevant product numbers, quantities, and shipment information, then attempt to match them with the corresponding purchase order and order lines.

But successful document interpretation would only be the first step.

The system would also need to determine whether the proposed quantities can be assigned to the intended shipment.

Are the product identifiers consistent? Are the quantities valid? Has any part of the order already been allocated elsewhere? Does the incoming document contain information that conflicts with existing records?

If the information is incomplete or contradictory, the system should not simply invent an answer.

It could request clarification, prepare a supplier inquiry, or present the unresolved issue to the import manager.

Where the information is sufficiently clear, it could prepare the corresponding operational changes.

Those changes would then need to pass through business validation and appropriate authorization before being committed to the operational records.

Finally, the system would need to verify that the intended changes were applied correctly and that the remaining open quantities were preserved.

The potential value is not limited to reading the packing list faster.

It lies in reducing the manual work required to translate incoming information into correct operational actions.

And importantly, the entire workflow does not need to be autonomous from the beginning.

Some steps may be executed automatically within defined limits. Others may remain subject to human approval. More complex exceptions may continue to require manual handling.

This is a hypothetical workflow illustrating the direction of our development, not a description of an already available KONKORD capability.

For us, it represents the difference between adding AI features to software and designing software around the possibility of AI-assisted execution.

Understanding the document is only the beginning. Completing the operational task requires understanding the business.

Why Reliable Execution Must Be Designed In

As software moves from providing information to performing actions, reliability becomes a different kind of challenge.

A misleading recommendation can cause problems if a user acts on it. An incorrect automated transaction can have an immediate operational consequence.

In supply chain management, those consequences may involve shipment assignments, inventory-related records, delivery commitments, additional transport costs, or communications with external partners.

This is why we do not believe probabilistic AI should independently determine every aspect of business execution.

Language models are valuable precisely because they can interpret uncertain information and respond flexibly to unfamiliar situations.

But business operations also depend on requirements that must remain consistent.

A shipment assignment must respect the relevant quantity rules. A user or agent must have the authority to modify a business record. A commercially significant decision may require explicit approval.

Our approach is to bring these capabilities together without treating them as interchangeable.

AI can support interpretation, reasoning, and the preparation of actions.

The operational system must provide the structured context and controls necessary to validate, authorize, execute, and verify consequential changes.

This direction is consistent with the principles of the NIST AI Risk Management Framework, which emphasizes governance, clearly defined responsibilities, context-sensitive risk assessment, and ongoing evaluation throughout the AI system lifecycle.

For KONKORD, this is an architectural principle guiding our development, not a claim that every component is already implemented.

Human control must also be part of the design.

An import manager should not necessarily have to approve every routine update. But neither should an AI system be free to commit the company to significant costs or contractual obligations without appropriate authority.

The degree of autonomy should depend on the nature of the task, the consequences of an error, and the permissions established by the organization.

We believe this distinction is fundamental to making AI useful in critical operations.

Trust will not come from a model that never makes mistakes. It must come from a system designed to recognize uncertainty, enforce boundaries, and keep consequential actions controlled and verifiable.

Start Narrow, Expand Deliberately

The ambition to build an AI-native operational platform can easily lead to the temptation to automate everything.

We believe the more useful approach is to begin with clearly defined operational tasks.

Supply chain management contains a wide range of activities with very different characteristics.

Some are largely deterministic. Others involve unstructured information but can be resolved through clear business rules once that information has been interpreted.

Still others require negotiation, commercial judgment, or decisions under substantial uncertainty.

There is little reason to use the same technical approach for all of them.

A conventional workflow may be entirely appropriate for validating a quantity or recording a container event.

AI may be valuable for interpreting a supplier email, identifying a discrepancy in a document, or proposing how an unexpected situation should be handled.

Combining both approaches can make it possible to automate tasks that neither technology would handle as effectively on its own.

This principle is also reflected in Anthropic's guidance on building effective agents, which recommends beginning with simple, composable solutions and introducing more complex agentic systems only where the added complexity demonstrably improves outcomes.

Our development direction is therefore to focus on bounded operational workflows, evaluate where AI creates practical value, and expand the scope of delegated work as the system becomes capable of handling it reliably.

This requires evaluating more than model performance.

We need to understand whether a workflow produces correct business outcomes, how frequently exceptions occur, what human intervention remains necessary, and whether the economic benefit justifies the complexity of automation.

More agents do not necessarily make a better system. Neither does more autonomous behavior.

The appropriate design is the one that completes the intended work reliably, efficiently, and within the boundaries established by the business.

Over time, individual workflows may become connected. A system that initially supports document interpretation could later participate in shipment preparation, supplier coordination, and related operational activities.

But such expansion should follow demonstrated capability rather than assumptions about what AI will eventually be able to do.

Building Toward Operational AI

We see AI-native software as an opportunity to change the relationship between people and enterprise applications.

Traditional software provides information, structure, and tools that employees use to manage operational work.

The next generation may increasingly participate in that work — interpreting information, preparing actions, executing authorized tasks, and coordinating activities across systems and organizations.

Supply chains provide a compelling environment for this development because so much operational effort is spent connecting information and processes that remain fragmented.

But the complexity of the domain also makes reliability essential.

Our starting point at KONKORD is therefore not a promise of complete autonomy. It is a structured understanding of operational work, an existing supply chain software foundation, and a deliberate approach to combining AI capabilities with reliable business execution.

There is substantial work ahead, both technically and operationally.

We believe the direction is worth pursuing because the opportunity extends beyond making existing software easier to use.

It is about changing what enterprise software can take responsibility for doing.

We are not starting with the ambition to automate an entire supply chain. We are starting with the work that makes supply chains run — and building toward a system that can increasingly help execute it reliably.