AI Agents for Freight Rail& Intermodal in 2026

Every conversation about AI agents in freight rail starts in the same wrong place. Someone asks which API to call. The answer that matters is that North American interchange rail is not a platform architecture at all. It is an industry-clearinghouse architecture, and the difference is not cosmetic — it changes what you buy, who approves it, what it costs, and what an agent is permitted to do once it is built.

The interchange data that makes a rail car movable across carriers does not live in any one railroad's cloud. It lives in shared industry systems operated by Railinc Corporation, a subsidiary of the Association of American Railroads, and it moves as ANSI ASC X12 EDIover Railinc's messaging switch, MQ, or FTP. That sentence contains the whole problem with an API-first plan. The transport is EDI. The counterparty is a clearinghouse. And the access model is a registered relationship rather than a self-serve credential.

Here is what makes this industry unusually tractable for an honest analysis: Railinc publishes its prices. Its 2026 price list — the copy we worked from carries the document header “Version 1.5 - 07242026” and states prices effective starting January 1, 2026 and valid until December 31, 2026 — puts a dollar figure on the things that in most industries are hidden behind a partner agreement. Railinc sells mailboxes: “Mailbox—TRAIN II (FTPTRNII) $30 per mailbox” and “Mailbox—Non-TRAIN II (FTPBASE) $100 per mailbox.” It bills EDI by the megabyte: “Switch Usage (EDISWITCH) $80 per MB,” with a “Minimum of $100 per month” and a note that switch usage is based on the volume of message data per month, where 1 MB = 1 million bytes.

It charges to add a counterparty — “Primary Account Setup (EDISETUP) $250” and “Customer's Trading Partners (EDISETUP) $250 per Trading Partner.” It charges to change a configuration — “Standard Configuration Change (MSGTABLE) $250 per entry” at five business days, or $500 per entry expedited at two business days. It charges to re-send messages you lost: data retransmission at “$250 per request” including one week of messages, plus $50 per additional day. And it positions itself directly against the alternative, stating that Railinc will help to reduce the delays and high costs associated with other value-added networks.

Read that list as an architect and the picture snaps into focus. The unit of integration here is a priced mailbox, a priced trading-partner relationship, a priced configuration change, and a per-megabyte meter. Add the data licence — customers may use such data for the customer's internal use only, are strictly prohibited from reselling, redistributing or repackaging it without written consent, and third-party access requires a Letter of Authorization, without which information will not be provided to a third party — and you have the honest answer to “why not just build an API integration.” An agent vendor acting on a shipper's behalf is a third party in this architecture. It needs paperwork before it needs code.

None of this means rail is closed. It means rail is legible, in a way most industries are not, and the legibility is the opportunity. You can price this integration before you write a line of code. Very few industries let you do that.

“What is the system of record?” has no single answer in rail, and pretending otherwise is the fastest way to scope a project that cannot be delivered. There are at least six, they are owned by different parties, and they answer different questions.

Systems of record in North American freight rail and intermodal, and the write path for each — Frenchy Digital analysis, August 2026.

Three observations follow from that table, and they should shape the entire architecture.

First, the read surface is far richer than the write surface. This is the structural pattern across every industry in this cluster, but rail states it in the plainest possible terms: you can buy Umler data by the row, subscribe to broadcast messaging, and receive movement events by webhook — while the act of registering equipment requires a reporting mark and an authorized human. Agents that only read are a solved integration problem here. Agents that write are a contract and certification problem, not an engineering one.

Second, the only system where you control the schema is your own.Your TMS, ERP or rail-billing platform is the one place in the list where you own the table, the migration and the rollback. That makes it the correct primary write target for an agent. This is not a compromise position — it is the architecture. The agent reads widely across systems it does not control and writes narrowly into the one it does, and a human moves anything from your system into someone else's.

Third, authorization here is relationship-based. Railinc requires an AAR-assigned reporting mark — Railinc's own example is a mark of the form ABCX — or a Railinc-assigned alphanumeric Company ID to reach many systems, and companies without one request one through Railinc's Onboarding Application. Umler is reached through Railinc Single Sign-On, and after SSO registration a user must separately request access to Umler and select the marks they are authorized for. Railinc's published Data Stewardship and Access policy states that it reviews access requests based on a requestor's relationship to the requested data.

That gap between internal identity and external standing is worth sitting with, because it is where audit trails get muddy. If your agent acts under a shared company credential into a carrier API, the carrier's log shows your company, not your agent. Your own per-action log is therefore the only record that can attribute a specific write to a specific agent run and a specific human approval. Build it before you need it, not after an invoice dispute.

Most integration cost discussions in this cluster end in “not publicly disclosed.” Rail is the exception, and it is worth laying the numbers out because they change design decisions rather than merely informing a budget.

Selected line items from Railinc's published 2026 price list, effective January 1 to December 31, 2026. Prices are as published; confirm the current list before contracting.

Four design consequences fall directly out of that table.

Chatty agents are expensive here in a way they are not on a flat-rate SaaS API. Switch usage meters message volume by the megabyte with a monthly floor, TRAIN II inquiries run per record, and Umler web-service extracts are priced per record returned. An agent architecture that re-queries on every reasoning step, or that retries aggressively without a backoff, produces a bill. Cache deliberately — within the limits of the internal-use licence — and design for incremental sync rather than repeated bulk pulls, since a full master Umler file is priced at $8,500 per request.

Your responsiveness to schema drift has a price and a lead time. A standard configuration change is $250 per entry at five business days; expedited is $500 at two. That is not a large sum, but it is a procurement step, and procurement steps during peak season are where integrations die. Establish a standing allowance and a pre-approved path before you need it.

Message loss has a recovery price, which tells you to persist everything. Data retransmission at $250 per request, covering one week and $50 per additional day, is Railinc telling you plainly that re-delivery is a service, not a right. Write every received message to durable storage before you parse it. The cheapest retransmission is the one you do not have to buy.

And the contrast at the bottom of the table is the single most useful pricing fact in rail. The registry and messaging plumbing is published to the dollar. The modern visibility and API products — Railinc's TransmetriQ shipper and owner platform, and RailSight, which delivers CLMs by FTP, MQ or webhook alongside 417 waybill messages, 421 trip plans, Demand Trace, Waybill, ETA and Trace API services, Terminal Activity and Last Free Day — are priced call for quote on every line item, including the ocean vessel and container tracing services. Published price signals commodity utility. Quote-only signals a negotiation, and in a negotiation your leverage is your volume.

The standards themselves are also licensed. X12 operates a multi-tier licensing program — commercial, internal, developer, a premium subscription and a code-list update subscription, alongside a free registered-user account for non-premium resources — and access to the EDI Standard requires a paid licence tier. The fee amounts are not displayed publicly.Write “licensed, priced on application” in your budget, not a number, and route it through procurement early.

If your team has only ever integrated against JSON APIs, the mental model to adopt is this: in rail, the contract between systems is a transaction set with an official number and a carrier-specific implementation guide, and the guide has a version that moves. Get the names right in your specification, because a developer working from a carrier guide will search for the official ASC X12 title, not the industry nickname.

Core rail transaction sets and the movement event stream. Transaction-set usage is well attested across Railinc and carrier implementation guides; the CLM description is from Railinc's own glossary.

Sitting behind that message set is Forward and Store, the industry system that notifies downstream carriers on interline moves. The originating railroad sends the 417 waybill into Forward and Store, which checks it for format and syntax compliance before forwarding it on. That is a meaningful architectural detail for an agent designer: there is already a validation checkpoint in the industry pipeline, and it validates syntax, not commercial correctness. A waybill can pass Forward and Store and still be commercially wrong. Your reconciliation logic is what catches the second kind of error, and it is the kind that costs money.

The failure mode deserves precision, because it determines your detection strategy. A version bump usually does not produce a clean parse error. It produces fields that land in the wrong place or resolve to defaults — a status code that now means something slightly different, a segment that has moved, a qualifier that was added. The agent keeps running. The numbers keep flowing. They are just wrong, and they are wrong in a direction nobody notices until a reconciliation stops matching or an invoice dispute is thrown out.

So the practical controls are boring and effective. Pin the guide version explicitly in configuration rather than implicitly in code. Keep the previous parser deployable so a rollback is a config change, not a release. Monitor the rate at which fields resolve to null or default and alert on a step change. And, most importantly, assign a named human to watch each carrier's EDI page. A dependency announced on a web page is an unmonitored dependency unless someone is monitoring the web page.

There is one genuine advantage to this world that is easy to miss. Batch and message-based rungs of the integration ladder get reconciliation for free, because the file is the checkpoint. A real-time REST write leaves you guessing whether it landed; a message set with an acknowledgement path and a downstream event stream gives you a natural place to compare what you believe against what the industry recorded. For an agent — which writes over unreliable networks and can be interrupted mid-plan — that checkpoint is an asset, not a legacy burden.

One of the most common scoping errors in this industry is assuming that “track the container” is one integration. It is not. Equipment identity in North American intermodal spans at least four separate identifier systems, with different governance and different access rules for each.

Umler is the registry of ownership, control and physical characteristics for rail equipment in North American interchange service. Railinc describes it as covering more than two million pieces of North American rail, steamship and highway equipment, states that it provides the critical information that rail carriers need for the safe and efficient loading, routing and handling of rail shipments, and that it enables users to track and manage pools and inspections. That phrase — safe and efficient loading, routing and handling — is the reason unattended agent writes into Umler are off the table. Physical characteristics are a safety input, not a data field.

Umler access is priced, and the price structure is informative. Semi-annual registration runs $100 semi-annually for a fleet of 1 to 81 units, and $1.00 per unit semi-annually for fleets of 82 or more. Umler Messaging Broadcast is $1,275 per subscription monthly by MQ or FTP — and that price is stated as applying to railroads, car owners and shops, with all others directed to call for a quote. Data extracts via web services are $0.01 per record returned, again for railroads, car owners and shops only. Web service setup and testing support is a $2,500 fee including ten hours of support, with additional support requiring increased billing.

Then there are the per-car annual fees, which matter for anyone modelling total cost of ownership across a fleet: car repair billing at $0.98 per car annually for car owners, DDCT at $0.69 per car annually, Equipment Advisory at $0.65 per car annually, EHMS registration supplement at $0.05 per unit annually, car service and car hire at $1.43 per unit semi-annually based on January and July Umler equipment counts, and the Tank Car Integrated Database at $0.48 per tank car semi-annually. Individually trivial; across a large fleet, a line item somebody in finance already knows about.

Alongside Umler, physical identification runs on Automatic Equipment Identification. AAR Standard S-918 specifies automatic electronic identification of rail transportation equipment — a reflected-energy passive RFID system with tags on both sides of rolling stock, active trackside readers, ten recommended frequencies from 902.250 to 921.500 MHz, and a nominal transmit power of 2.0 W.

Intermodal containers additionally carry ISO 6346 owner and equipment codes, with prefixes issued by the BIC — well attested in the industry, though we did not verify it to a primary source in this pass. Motor carriers operating under the intermodal interchange agreement are identified by a SCAC, which is one of the registration requirements under the UIIA. We did not verify which body administers SCAC codes and will not assert it — which is itself a useful illustration: four identifier systems, separately governed, and a consultant who has not checked all four is guessing about at least one.

The design conclusion is straightforward and it saves projects. Build an identity resolution layer as its own component, early, and treat it as the hardest part of the read integration. Reporting mark and car number, AEI tag read, ISO 6346 container code and chassis identity under the interchange agreement all describe overlapping physical reality through non-overlapping identifier spaces. An agent that cannot confidently join them will produce confident, wrong answers about where things are.

The industry's reputation says there are no APIs. The reputation is wrong, and the correction is more interesting than the myth. The Class I railroads do publish customer APIs. What they do not publish is self-serve access.

Carrier and clearinghouse API posture as verified in our August 2026 research pass. Where we could not verify a carrier's posture, we say so rather than infer it.

Two details in that table deserve to be pulled out, because they are the clearest statements available anywhere in heavy industry about how machine access is actually governed.

Union Pacific's Action API is a documented, carrier-operated write path. Equipment release, rail car ordering, intermodal terminal reservations — real actions with physical consequences, exposed through a published developer program. If you need one example of a genuine agent-actionable write API in heavy industry, this is it. And the gate on it is instructive: developer registration, acceptance of Union Pacific's rates and terms, and, for third-party providers, an active Letter of Authority with Union Pacific, with third-party provider administration handled by PS Technology. EDI remains offered in parallel. So the modern write path exists, and it is gated by a legal instrument rather than a consent screen.

BNSF's authorization model is a party-role on a transportation document. Companies must appear on the waybill to access shipment data. Third parties need Letters of Authorization. There is a ZS monitoring role granted when shippers authorize third parties, and BNSF states it can be set in the EDI request or in the AWI web application that creates the waybill. Read that as an architecture statement: your permission to see a shipment is not a token scope, it is who you are on the document. That is a fundamentally different permission model from anything in modern SaaS, and it means the correct first question in any rail agent project is not “what API key do we need” but “which of our customers' waybills name us, and where are the LOAs.”

What about the rung below? Screen scraping and RPA against a carrier portal is technically possible and contractually the worst position available to you, and this deserves an honest treatment rather than a dismissal. The case everyone cites for scraping's legality does not say what it is usually claimed to say. In hiQ Labs v. LinkedIn the Ninth Circuit was ruling on a preliminary injunction under a sliding-scale standard, and its conclusion on the Computer Fraud and Abuse Act leg was, in the panel's own words, that “HiQ has therefore raised serious questions about whether LinkedIn may invoke the CFAA to preempt hiQ's possibly meritorious tortious interference claim.” A serious question is not a holding that scraping is lawful.

And the commercial ending is the part that matters. On remand, a November 2022 summary judgment held that hiQ had breached LinkedIn's user agreement, and a December 2022 stipulated consent judgment carried $500,000 against hiQ plus a permanent injunction requiring it to cease scraping and destroy source code, data and algorithms derived from scraped profile data. Terms-of-service breach and CFAA liability are different questions with different answers, and the contract claim is the one that bit.

On the statutory side, Van Buren v. United States is also routinely overstated. The Court held that an individual “exceeds authorized access” when he accesses a computer with authorization but then obtains information located in particular areas of the computer — such as files, folders, or databases — that are off limits to him. It described the framework it went on to adopt this way: “Under Van Buren's reading, liability under both clauses stems from a gates-up-or-down inquiry—one either can or cannot access a computer system, and one either can or cannot access certain areas within the system.” But it expressly reserved the question that everyone assumes it settled, stating: “For present purposes, we need not address whether this inquiry turns only on technological (or ‘code-based’) limitations on access, or instead also looks to limits contained in contracts or policies.”

Apply that to rail specifically. Railinc's own terms restrict data to the customer's internal use, prohibit reselling, redistributing and repackaging without written consent, and require a Letter of Authorization for third-party access — and Railinc states that it may modify the Terms of Use without prior notice, effective upon posting. That is an explicit contractual regime, agreed to by a party who registered for access. It is precisely the position in which hiQ lost. Do not build a rail agent's data supply on a portal you scrape.Use it, if you must, for something low-stakes and low-volume, with counsel's sign-off, and with a plan for the day the portal changes — which it will, without notice or versioning, because a presentation layer carries no compatibility promise.

If you build one agent in this industry, build the demurrage reconciliation agent. Not because the workflow is glamorous, but because of a structural gift almost no other industry in this cluster receives: the regulator already specified the schema.

49 CFR Part 1333 governs demurrage liability. Section 1333.4, adopted April 6, 2021 at 86 FR 17750, requires Class I carriers to include specified minimum information on demurrage invoices. Here is the enumerated field set, and it reads like an integration specification because functionally that is what it is.

Minimum information required on Class I demurrage invoices under 49 CFR § 1333.4, adopted April 6, 2021 (86 FR 17750), as reproduced by Cornell LII.

Two of those requirements are worth quoting exactly, because they are the join keys your whole reconciliation depends on. The rule requires “the unique identifying information (e.g., reporting marks and number) of each car,” and it requires “the dates and times of: Original estimated arrival of each car… Receipt of each car… Actual placement of each car.” It further requires “the number of credits and debits attributable to each car (if applicable).” A federal rule enumerating both an equipment identifier and a timestamp triple is, from an integration standpoint, an extraordinary gift.

There is more. Section 1333.5 addresses machine-readable accessto the § 1333.4 information. We confirmed that the section exists and concerns machine-readable access; we did not read its full text and will not paraphrase provisions we have not read. The Surface Transportation Board's own summary of the Ex Parte 759 rulemaking describes a machine-readable data requirement so that rail users have the option to access machine-readable data containing the minimum information. Separately, under EP 759 a Class I carrier is required to bill the shipper directly rather than the warehouse for destination demurrage, conditioned on a shipper–warehouse agreement communicated to the railroad.

Now the clock, which is where most demurrage programs quietly fail. Railinc's published terms give 90 days from invoice date to raise a billing discrepancy, after which discrepancies are considered an accepted variant and therefore waived. That single sentence invalidates the most common operating model in this space — a quarterly reconciliation performed by a stretched finance team. A quarterly cycle is structurally too slow at the boundary: some portion of every quarter's exceptions ages past the window before anyone looks at it.

So the agent's design is set by the clock, not by the model. It reconciles on the carrier's invoicing cadence. It ages every open exception from creation. It escalates at a fixed threshold — we generally recommend 60 days — rather than when someone notices. And it surfaces the aging as a first-class metric, because “dollars at risk of waiver in the next 30 days” is the number that gets an operations director's attention in a way that “exceptions detected” never will.

Intermodal is a different instrument entirely, and conflating the two is a category error. Equipment interchange between intermodal trucking companies and equipment providers runs on the Uniform Intermodal Interchange and Facilities Access Agreement, administered by the Intermodal Association of North America. IANA's own description is precise and worth quoting exactly:

“The UIIA is the only standard industry contract that outlines the rules for the interchange of equipment between intermodal trucking companies and equipment providers (ocean carriers, railroads & equipment leasing companies).”

— Intermodal Association of North America, intermodal.org/uiia

Note the verbs. IANA says the agreement outlines the rules forinterchange — not that it governs interchange. That distinction matters when you are writing a system that reasons about obligations, and it is a good habit generally: do not upgrade a source's verbs when you restate it.

Under the UIIA, Per Diem is defined as a charge payable when intermodal equipment is not returned by the end of allowable free time to its origin or another provider-specified location. Disputes over maintenance, repair, or per-diem and detention invoices go to binding arbitration administered exclusively by IANA through its Dispute Resolution Panel. A UIIA version effective May 5, 2026 exists. On the commercial side, the motor carrier annual administrative service fee was $399.00 effective January 1, 2025, with a discount for IANA members, while equipment providers pay on a formula based on total annual volume, data access, and the number of motor carriers serviced. We could not confirm a 2026 fee schedule; treat those as the 2025 figures and verify before you rely on them. Registration requires a SCAC, USDOT or MC number, tax ID or EIN, insurance documentation and the fee.

One number we will not print. There is a widely circulated figure putting the annual industry cost of demurrage and detention in the tens of billions of dollars. We chased it and found no traceable origin — it appears in freight-marketing content and nowhere else. A second, larger figure describing multi-year collections by nine carriers is ocean demurrage and detention under a different regulator, with different rules and different counterparties. Using it in a rail conversation would be a category error even if the number is right. Build your business case from your own ninety days of invoices. It will be more persuasive to your CFO than any industry figure, and it will be true.

Finally, a related data surface worth knowing about. The Surface Transportation Board's reciprocal switching final rule created 49 CFR part 1145, effective September 4, 2024, allowing shippers to petition for a prescribed reciprocal switching agreement with eligibility keyed to objective service standards — reported thresholds include at least 70% on-time performance, transit time not increasing more than 20% year over year, and at least 85% success on industry spot and pull, the first-mile and last-mile measure. Class I railroads are required to submit standardized service data on an ongoing basis, published in generalized form, and to provide individualized, machine-readable service data on request. We did not verify the current state of implementation or any extensions granted, and we will not date-stamp its status. But the direction of travel is clear, and it is the same as demurrage: where shippers have pressed a regulator, machine-readable data has followed.

Every article about agents in heavy industry should state its safety boundary explicitly, and in freight rail the boundary is unusually easy to state because federal regulation draws it for you.

Positive Train Control sits under 49 CFR Part 236 Subpart I, with § 236.1005 setting requirements for PTC systems and § 236.1021 governing requests for amendment. Before a railroad can make certain changes to an FRA-certified PTC system or its FRA-approved PTC Safety Plan, the host railroad must submit and obtain FRA approval of a Request for Amendment under § 236.1021, and § 236.1021(h) enumerates the change types that trigger one — including modification of a safety-critical element. Where an RFA seeks approval of a material modification of a signal or train control system, FRA publishes a Federal Register notice and invites public comment under 49 CFR part 211, and may approve, approve with conditions, or deny at its sole discretion.

This is live machinery, not a historical artefact. Federal Register RFA notices in 2026 include Amtrak on January 13, PATH on April 16 — seeking approval for a software update associated with placing a new interlocking into service — MBTA on August 3, and the Belt Railway Company of Chicago on August 12. A railroad wanting to ship a software change associated with a new interlocking files a notice and waits for a federal agency.

We should be careful about what we are not claiming. We did not verify any restriction on the commercial or business use of PTC-generated data, nor the messaging architecture beneath PTC, nor back-office server specifics, and we will not describe them. The argument does not need them. It needs only the regulatory fact: safety-critical change here is a filing, not a deploy.

The adjacent regulatory clock worth knowing is 49 CFR Part 225 accident and incident reporting, which runs on Form FRA F 6180.54 for reportable rail equipment accidents, alongside 6180.55a for employee injury and illness and 6180.57 for highway-rail grade crossing incidents. Railroads may submit electronically over the internet or on optical media in lieu of hard copy for those forms, and Part 225 allows 30 days after the end of the month in which the incident occurred, though a railroad need not wait. Grade crossing incidents exceeding the current reporting threshold for damage to on-track equipment, signals, track, track structures or roadbed are reported on 6180.54. We did not verify the current dollar threshold — it is indexed and changes — so do not let any system hard-code one.

That last point generalises into a design rule that applies well beyond rail: an agent must never cache a regulatory threshold, rate or deadline that is subject to periodic revision.It should fetch the published value at time of use, together with its effective date, and refuse to proceed if it cannot. An agent that confidently applies last year's threshold is worse than an agent that stops and asks.

With the boundary established, here is the working allocation of authority we recommend for a rail and intermodal agent. This table is the artefact to put in front of your operations leadership, your safety group and your counsel before the build starts — not after.

Human-in-the-loop boundary for a freight rail and intermodal agent — Frenchy Digital recommended allocation, August 2026.

Our pillar article on integrating agents with legacy systems defines a five-rung ladder: documented public API, certified partner program, EDI or batch file, screen scraping or RPA, and no path at all. Each rung down means less vendor cooperation, more fragility and more contractual exposure. The useful exercise for any rail project is to place each workflow on the ladder honestly, because you are on exactly one rung per workflow, whatever your architecture diagram says.

• Rung 1 — Documented public API: Real here, and narrower than it looks. Union Pacific, BNSF and Norfolk Southern publish developer programs, and UP's Action API is a genuine write path. But check the write surface before you architect: a documented API with no write path for your use case is a lower rung wearing a Rung 1 badge.
• Rung 2 — Certified partner program: This is effectively where third-party agent vendors sit. The Letter of Authority, the LOA-gated third-party data access, the 'railroads, car owners and shops — all others call for quote' pricing qualifier, and the call-for-quote posture on TransmetriQ and RailSight are all partner-program mechanics under different names. Model the fees as recurring, and remember the terms are the counterparty's to draft.
• Rung 3 — EDI / batch file: The backbone, and in rail it is the current production interface rather than a legacy one — priced, actively version-managed, with a 2026 price list and a carrier-wide 2025 version upgrade. For an agent, EDI is often the safest write path precisely because it is message-based: it has a natural reconciliation checkpoint.
• Rung 4 — Screen scraping / RPA: Technically possible against carrier and terminal portals, contractually the weakest position available, and structurally fragile because you are consuming a presentation layer that can change without notice or versioning. Rail data licences make the contract exposure explicit. Use only for low-volume, low-stakes data, with counsel's sign-off.
• Rung 5 — No path at all: Real and common, and the correct answer for anything safety-critical. Train control has no third-party write path at any price. The honest options are to keep a human in the loop for the write step, change the counterparty, or wait for a regulatory forcing function — and in rail, regulatory forcing functions demonstrably work: § 1333.4 is one.

A word on the protocol layer, because it comes up in every vendor conversation now. The Model Context Protocol published a new specification dated 2026-07-28, whose headline architectural change is that MCP moved from a bidirectional stateful protocol to a request/response stateless one, with session state becoming explicit server-minted handles passed as ordinary tool arguments. Governance moved to the Linux Foundation. That is a real breaking-change story for anyone who built against the prior stable specification, and it tells you something about cadence: a stateless rewrite roughly eight months after the previous stable spec.

The same discipline applies to the security layer. The MCP specification's own security document is worth reading precisely because of what it is about: it mandates, for example, that “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server”; it requires per-client consent checks in proxy servers before forwarding to a third-party authorization server, with exact-match redirect URI validation; and it warns against wildcard or omnibus scopes, naming the risk of an expanded blast radius where a stolen broad token enables unrelated tool and resource access. Every one of those is a blast-radius control. None of them prevents prompt injection. That structure is the tell, and it is the honest state of the field.

Which brings us to the risk that most rail teams underestimate. An agent that reads inbound carrier correspondence, terminal notices, or PDFs from a counterparty is consuming untrusted content. If that same agent holds a credential that can write into a system of record, and can communicate outward, it has all three legs of what Simon Willison named the lethal trifecta: access to private data, exposure to untrusted content, and the ability to externally communicate in a way that could be used to steal data. On whether it is fixable, Willison is blunt: “we still don't know how to 100% reliably prevent this from happening.” On vendor detection claims, he notes that they almost always carry confident claims of catching 95% of attacks or similar — and that in web application security, 95% is very much a failing grade.

The prescription is architectural rather than filter-based: do not combine all three legs in one agent. Split the reader from the writer. The document-reading agent gets no write credential and no outbound channel beyond writing a structured record into your own store. The writing agent accepts only validated, structured input from that store — never free text that originated outside your organisation. This is not a solved-problem claim. It is blast-radius reduction, and it is the only honest thing on offer. The current OWASP GenAI LLM Top 10, published 4 August 2026, puts LLM01:2026 Prompt Injection at the top; for agents with tool access to production systems the priority pair is LLM03:2026 Excessive Agency and LLM10:2026 Improper Output Handling, with mitigations for excessive agency that are exactly the boring ones — least privilege, confirmation for high-impact actions, and tool-usage logging.

One last engineering note, because it is where duplicate writes actually come from. There is no standard for idempotency keys. The relevant IETF work, draft-ietf-httpapi-idempotency-key-header, reached revision -07 in October 2025 and is expired — it is not an RFC. The de-facto convention is Stripe's, and Stripe's own documentation contains the detail most teams miss: keys may be pruned after at least 24 hours, and “We generate a new request if a key is reused after the original is pruned.” Idempotency has an expiry. A retry a week later is a new write. So derive keys from business intent rather than from the attempt, persist them before the call rather than after, keep your own dedupe table alive longer than any downstream retention window, and never let the model choose the key — non-determinism in key generation is indistinguishable from having no idempotency at all.

What follows is the sequence we would run for a shipper, a third-party logistics provider or a car owner starting from nothing. Each phase has an owner, an entry criterion, an exit criterion and an explicit answer to “what do we do when this phase fails.” The week ranges overlap deliberately — phases hand over rather than terminating.

Recommended phasing for a freight rail and intermodal agent programme — Frenchy Digital, August 2026. Adjust week ranges to your seasonality; do not adjust the sequence.

Three notes on running this well.

Phase 0 is not a formality and it is where projects are actually saved.Rail integration engagements routinely start with a team that cannot say, in writing, which Letters of Authority they hold, which carrier credentials are active, whose mark their data moves under, or when any of it expires. That is not an unusual state of affairs — this paperwork accumulates over years across operations, finance and IT. But you cannot design permissions for an agent on top of an entitlement inventory that does not exist. Three weeks of archaeology is cheap compared with discovering at week fourteen that the feed you built on runs under a customer's LOA that lapses next quarter.

Phase 2's exit criterion is deliberately a human agreement rate, not an accuracy metric.There is no independent benchmark for agent performance on demurrage exception detection, and we are not going to invent one. What you can measure is whether your own demurrage analyst — the person whose judgement you are trying to scale — agrees with the agent's ranking on reviewed items, consistently, over more than one week. That is a real, checkable, internally-owned bar. Any vendor offering you an accuracy percentage for this workflow is quoting a number nobody has independently verified.

And Phase 3 has a legitimate stopping point. If the analyst edit rate stays high, the correct response is usually to narrow the agent to evidence assembly and let the human write the argument. Teams treat that as failure. It is not. Assembling a complete, cited evidence package for a demurrage dispute — every relevant invoice field, every matching event record, the constructive placement history, the credits and debits arithmetic — is most of the work and all of the tedium. If the agent does that reliably and a human writes three sentences, you have shipped something valuable and low-risk.

Integrations in this industry do not fail dramatically. They drift, and the drift is invisible until a reconciliation stops matching or a dispute is thrown out on a technicality. Here are the specific failure modes for rail and intermodal, each with the detection signal and the rollback.

Rail-specific integration failure modes — Frenchy Digital analysis, August 2026.

The counterparty-consolidation row deserves elaboration, because it is the best example available in any industry of “your integration counterparty may not exist in its current form,” and unlike most such warnings it has a docket and an SEC filing behind it.

The Union Pacific–Norfolk Southern transaction is live before the Surface Transportation Board. The joint application was filed December 19, 2025; the STB found it incomplete on January 16, 2026; a revised application was filed April 30, 2026; the STB accepted it as complete effective May 28, 2026 while holding proceedings in abeyance and requiring supplemental information by July 27, 2026; and the applicants supplied supplemental information on July 7 and July 27, 2026, adding customer protections. Union Pacific's own Form 10-Q states that the acquisition is currently expected to be completed in 2027.

One more item worth naming, because it will come up when your team starts reasoning about interchange rules. AAR Circular OT-10 exists and was revised in August 2026, and it is hosted publicly. We downloaded it and could not extract readable text, so we cannot tell you what it says and we will not describe its contents. If your workflow depends on it, obtain and read it — do not let a model summarise a document nobody on your team has opened.

Finally, a note on rate limits. BNSF publishes none. That absence is itself operational information: you cannot design your retry and backoff strategy from documentation, so you must derive it from observed behaviour, agree it with your carrier contact, and — given Railinc's per-record and per-megabyte metering elsewhere — instrument your own call volume as a cost signal rather than only as a performance signal. A retry storm in this industry shows up on an invoice.

Frenchy Digital scopes agent work in four bands. These are the same figures we use across every industry, because the work is shaped by workflow complexity and integration depth rather than by sector.

Frenchy Digital engagement bands, August 2026. Every engagement receives a written fixed-price phased proposal within 5 business days of the discovery call.

Senior-led delivery runs $150–$225 per hour, with ongoing retainers from $2,500 to $9,500 per month. Every build carries a 30-day post-launch warranty. Full source-code and IP ownership transfers to the client on completion — you are not renting your own integration. We are a senior-led, Black-owned agency based in Los Angeles, and the people who scope your project are the people who build it.

On payback: build the case from your own ninety days of demurrage and per-diem invoices reconciled against your own event data, not from an industry figure. Count the exceptions you can evidence, the dollars attached to them, and the proportion that aged past a dispute window last year because nobody got to them. That is a defensible number in front of a CFO, it is specific to your lanes and your carriers, and it is the only kind of number this article is willing to help you produce.

Rail attracts a particular kind of vendor pitch: heavy on visibility dashboards, light on the contractual mechanics that determine whether any of it can be operated. Here is what to listen for.

Vendor-selection red flags for freight rail and intermodal agent projects — Frenchy Digital, August 2026.

Two additions that do not fit neatly in a table.

Be sceptical of any vendor whose security story is a detection percentage. Prompt injection is unsolved, and the people closest to the problem say so. A vendor claiming its filter catches a high percentage of injection attempts is describing accuracy theatre; a vendor describing scoped, short-lived credentials, a human approval on the write step, a reading agent that holds no write credential, and per-action audit with reversibility is describing blast-radius reduction. The second is real. The first is marketing, and the difference is easy to hear once you know to listen for it.

And be sceptical of a roadmap that puts autonomy at the end. In this industry the constraint on autonomy is not model capability that will improve next year — it is a Letter of Authority, a party-role on a waybill, and a federal filing requirement for safety-critical change. Those do not resolve on a product roadmap. A vendor who presents human approval as a temporary limitation to be removed in a later release either does not understand the industry or is hoping you do not.

This section exists because the alternative is worse. Every article about a specialised industry contains claims the author did not check, and the honest thing is to say which ones. Here is what we could not establish in this research pass, stated plainly so you can route around it.

• The full text of 49 CFR § 1333.5: We confirmed the section exists and concerns machine-readable access to the § 1333.4 information. We did not read its full text and have not characterised its provisions beyond that. Read it before you build a compliance argument on it.
• The AEI tagging coverage figure: The widely repeated claim that more than 95 percent of the North American rail fleet is AEI-tagged, attributed to AAR, reached us only through RFID-vendor and trade sites. We could not reach an AAR primary source and will not print it as fact.
• SCAC administration: We did not verify which body administers SCAC codes in this pass and have not asserted it, even though the code itself is a registration requirement under the UIIA.
• The contents of AAR Circular OT-10: The document exists and was revised in August 2026. Our text extraction failed. We cannot describe what it says.
• The 2026 UIIA fee schedule: The motor carrier annual administrative service fee of $399.00 is the figure effective January 1, 2025. We could not confirm a 2026 schedule. Treat every UIIA fee in this article as the 2025 schedule.
• Norfolk Southern's and CSX's API posture: We confirmed that NS operates a developer hub at developer.nscorp.com but did not read its contents. We did not verify CSX's API posture at all and have asserted nothing about it.
• Current reciprocal-switching implementation status: The rule and its reported service thresholds are documented. We did not verify the current state of implementation or whether any extensions have been granted, and we have deliberately not date-stamped its status.
• The FRA Part 225 monetary reporting threshold: It is indexed and changes. We did not verify the current figure and no system should hard-code one.
• PTC data commercial-use restrictions and messaging internals: We did not verify any restriction on the commercial or business use of PTC-generated data, nor the underlying messaging architecture or back-office server specifics, and have described none of them.
• Any independent measurement of agent outcomes in rail workflows: We found no independent, methodologically-disclosed study of agent performance on demurrage reconciliation, exception triage or any other rail workflow. Every performance figure in this market is vendor-published. That absence is the most important limitation on this page.

There is a general rule underneath all of that, and it is worth stating once out loud. In this industry the credible numbers come from federal statistical programs and regulatory dockets — the Surface Transportation Board, the Federal Railroad Administration, the Federal Register, and published tariffs and price lists — and they are free. The uncredible numbers come from vendors quantifying the problem they sell the fix for. When both are available on the same topic, citing the vendor is a choice, and it is one you can hear a consultant make in real time.

A closing thought about where this leaves a shipper or a car owner in 2026. The reputation of freight rail as a technologically closed industry is out of date in one direction and understated in another. It is out of date because carriers publish developer programs, one of them exposes a real write path, and a federal rule has already specified the schema for the single most disputed invoice in the business. It is understated because none of that access is self-serve: every route in runs through a registered mark, a Letter of Authority, a party-role on a document, or a certificate from a well-known CA.

That combination is unusually good news for anyone willing to do the unglamorous work. The paperwork is knowable and mostly priced. The message set is documented and stable between announced version bumps. The dispute workflow with the clearest payback is running against a regulated field list with a published clock. What it demands is a team that treats the contract as part of the architecture — and an agent designed, from the first sprint, around the fact that it can only be as autonomous as its write path allows.