Pallet Fabric Gives AI the Keys to AS/400

The instructions were on paper

At Eassons, an account manager had assembled a recipe card holder. One card for each customer. The recipes concerned freight: temperatures, conversions, delivery schedules. The kind of detail that determines whether an order is entered correctly, yet can live outside the software meant to manage it. Pallet describes the cards in its Eassons customer story. They are a useful place to begin. Eassons case study ↗

Imagine handing an AI agent a shipment request. Reading the attachment is only the opening move. Someone still has to identify the customer, find the right destination, understand the instructions, and commit the result to the transportation management system. A convincing answer in a chat window leaves all of those obligations outstanding.

That gap gives Pallet Fabric its purpose. Fabric is the connection layer that makes systems of record and human interfaces usable as reliable agent tools. The customer keeps the systems that hold the business. The agent gains ways to work inside them.

Follow that idea far enough and you arrive at an unlikely test of modern AI: can it complete a transaction on an AS/400 green screen? A familiar-looking demo proves little if the actual order is waiting behind a terminal the agent cannot reach.

A doorway into the existing business

A system of record is where an operation commits its official facts: a booked shipment, an approved charge, an updated delivery appointment. Fabric connects an agent to those destinations. It should be understood as operational access, rather than another database customers must migrate into.

That distinction changes the deployment question. Instead of asking where the business will relocate its records, ask how the agent will read and change the records already there. What can it retrieve? What can it write? Which steps require approval? How will it know a submission succeeded?

Pallet’s agent platform lists email, inbound and outbound voice, PDFs, spreadsheets, scanned images, REST APIs, EDI, browsers, and remote desktop. These are different doors into the same working day. A customer can start a request in an inbox, send supporting material as a document, and expect the outcome to appear in a portal. Agent platform ↗

Each door demands its own handling. A document supplies information. An API exposes defined operations. A browser presents forms and confirmation screens. A desktop application may require a sequence of interactions before a record can be saved. The connective work is turning those differences into usable actions.

The model can decide what should happen. Fabric supplies access to the places where it must happen.

The green screen is a business constraint

Pallet co-founder Sushanth Raman has publicly announced direct AS/400 support, describing agents performing order entry, lookups, updates, appointment scheduling, bill-of-lading processing, and invoice coding. That is a specific claim about reaching a legacy operating environment, beyond merely extracting information from documents. AS/400 announcement ↗

AS/400 is still the name many operators use for systems in the IBM i lineage. The green-screen interface belongs to the 5250 terminal world. IBM’s current documentation describes reading virtual-terminal data in that format; the interface remains part of the supported technical landscape. IBM terminal documentation ↗

Age alone tells you little about an application’s importance. A screen can look dated while remaining the place where an enterprise has encoded years of working rules. Replacing it may mean retraining staff, reconciling records, and revisiting processes that already function.

Nor does a green screen mean IBM i has no APIs. The practical issue is whether a particular application exposes the operations an agent needs. When it does not, remote interaction offers another route. Pallet’s platform expressly includes desktop applications without APIs. Agent platform ↗

This removes a common integration veto: the automation project no longer has to stop simply because its last step lives in a desktop interface. It still has to prove it can navigate, act, and verify the outcome. Getting through the door begins the test.

One load, several languages

Consider an illustrative load-entry workflow. A tender arrives by email with a PDF attached. The agent extracts locations and shipment requirements, then checks the TMS for existing records. It retrieves missing identifiers, applies the customer’s operating instructions, and submits the completed load. A confirmation becomes the evidence that the task is finished.

At every handoff, something can change meaning. The customer’s location name may differ from the system’s location code. A spreadsheet column may use a customer’s preferred unit. A browser may accept a form while leaving the transaction pending. Reliable execution requires resolving those differences and checking the resulting state.

The tools should fit the step. An available API can support a lookup or submission; a portal may require browser interaction; a legacy application may require remote desktop. For a phone-led process, voice becomes another channel. These are routes through a workflow, rather than competing definitions of automation.

A useful operational test is a duplicate. If a submission times out, did it fail, or did the record save before the response disappeared? Retrying without checking can create a second load. That example shows why connectivity has to support observation as well as action.

Treat this sequence as an explanation of the architecture, not a claim that every Pallet deployment uses every channel. The business process determines which surfaces matter.

The map is bigger than a TMS

Pallet’s current agent page displays McLeod, Trimble, CargoWise, Blue Yonder, Manhattan, SAP, and Oracle among the existing software it integrates with. The spread matters: transportation, forwarding, warehouse, and enterprise applications can all sit along a single chain of work. Agent platform ↗

The broader ecosystem in this story also includes NetSuite, DAT, project44, Turvo, and Revenova. They occupy different roles. NetSuite belongs to the enterprise and financial systems layer. DAT provides freight-market tools and data. project44 supplies visibility and a growing execution platform. Turvo and Revenova supply transportation applications.

The vendors themselves describe an interconnected market. Turvo lists NetSuite, DAT, and P44 in its integration ecosystem. DAT explains how customers can retrieve data and post loads through APIs. Revenova describes its TMS as built on Salesforce. Turvo ecosystem ↗ DAT APIs ↗ Revenova platform ↗

This map explains the environments a connection layer must work across; it does not establish a certified Pallet connector for every named product or every operation. The concrete deployment evidence here is TruckMate.

For an operator, the unit of work is the shipment. For a software vendor, the unit of product is usually an application. Fabric’s architectural promise is to bridge that mismatch, allowing an agent’s task to continue when the work crosses an application boundary.

TruckMate supplies the proof

Eassons’ deployed agent reads tenders, enriches shipment data through API lookups, and posts loads directly into Trimble TruckMate. Pallet reports 98% touchless load building, 85% load-entry cost savings, and production deployment in 40 days. New edge cases go to human operators. These are results from that customer deployment. Eassons case study ↗

The last step carries particular weight. The completed record lands in the TMS staff already use. That is the point at which document understanding becomes operational execution.

“

Pallet is automating our button-pushing, so our team can focus on high-touch account management and sales.

Will Easson · VP Continuous Improvement
Eassons customer story ↗

Read the result through that lens. The value of the connection layer is the portion of a process it can complete, including the unglamorous lookups and submissions between the incoming request and the saved record. The outcome gives a team more room to handle customers and exceptions.

The cards also reveal why access and knowledge have to work together. A connection can expose a field, but the correct value may depend on a customer rule. Pallet separately describes Memory as the home for operating procedures and institutional knowledge. Fabric provides the route into the working system. Pallet platform overview ↗

A good deployment must bring both to the same transaction.

The boundary is the workflow

Pallet can complement a system of record by performing work inside it. It can also complement a visibility tool: a shipment signal can inform a next action elsewhere, such as updating an appointment or preparing a customer response. That is the architectural opportunity described here, rather than evidence of a particular project44-to-Pallet deployment.

The competitive boundary needs care. project44’s current platform includes AI agents and workflow orchestration. Its Intelligent TMS can operate as a complete system or alongside an existing TMS. A comparison that treats project44 as a passive map would miss its present product scope. project44 platform ↗ project44 Intelligent TMS ↗

TMS-native AI has an obvious advantage when the necessary data and actions are already inside its own environment. Its limits appear when a task depends on something outside the database or beyond the vendor’s supported integrations and release cycle. Those limits vary by product; native AI is not universally confined to one database.

A separate execution layer earns its place by completing the remaining steps across systems. That is the useful distinction to test: where does the workflow stop, and who has to pick it up?

Return to the incoming tender. The destination is a valid load in the operating system, with exceptions routed to someone who can resolve them. Pallet Fabric’s promise becomes tangible at that destination. The green screen can stay. The order still has to get entered.