AI Enablement for TMS

TMS is a vertically integrated fourth-party logistics company. They run warehousing, cross-dock, last mile, freight brokerage, freight forwarding, and value-added logistics across Miami, Mexico, and Austin. They’re not a software company. They move freight, and they use AI and technology to track shipments end to end.

But AI had already shown up inside the business. One of their leaders (a non-developer) had used Claude to build a production-grade track-and-trace system for their Mexico operations in a matter of weeks. Others were experimenting with AI tools independently. None of this was coordinated. There were no agreed-upon tools, no governance, and no process for deciding what was okay to build and what wasn’t. This is where most companies are today.

Their CEO, Hector, wanted his leadership team to embrace AI so they could cascade it into their departments and find opportunities. That’s what he brought us in for.

Preparing for the Engagement

Before the session, TMS sent us an 13-page slide deck outlining their current tools, systems, and technology landscape. We spent time researching their stack. Over 20 applications across the business, mixed data quality, no single source of truth. We also studied the AI projects already underway to understand what had been built and how.

Then we spent an hour with Hector. That conversation changed the engagement. What became clear was that this wasn’t a “teach people how to use AI” problem. It was an organizational problem. There was no governance. There were no agreed-upon tools. People were building things on their own with no oversight. Hector’s real concern was that someone’s unsupervised project could take down the company.

The engagement shifted from enablement to strategy.

The Session

We brought in Sid Gupta, who supports technical implementation on these projects, and spent a full day with 14 of TMS’s leaders. People traveled in from multiple locations; it wasn’t a casual check-in. TMS treated it with the seriousness it deserved.

We structured the session around three questions:

What’s already happening with AI at TMS?
What’s allowed?
What do we work on next?

We also ran an exercise we call “How to Kill the Company.” Instead of lecturing the room about AI risk, we had the group brainstorm: if you were trying to take down the company using the AI tools and access you have today, how would you do it? What could go wrong from vibe-coded software? What vulnerabilities open up? What cascading effects could destroy crucial data or break key workflows? Five minutes of brainstorming made the risks concrete in a way that a slide about best practices never would. When the people in the room are the ones naming the threats, they take governance seriously.

The first question surfaced a lot. Multiple people were building AI-powered tools independently. Some of it was impressive. The Mexico track-and-trace project was already being positioned as a competitive differentiator — one leader had already demoed it to a Fortune 500 client, who was impressed. But none of it was coordinated, and no one had a full picture of what was happening across the organization.

The second question forced decisions the company had never made. What tools are we standardized on? Who’s allowed to build what? What needs approval and what doesn’t? These conversations had simply never happened, even though AI was already in production.

The third question, what to work on next, became the natural bridge into the next phase. Once the room saw how much foundational work needed to happen on governance and tool standards, it was clear that locking those in was the highest-leverage use of the day. The opportunity identification work follows from here.

What Came Out of It

By the end of the session, TMS had made real decisions and put them in writing:

A steering committee. Three leaders appointed to own AI decisions for the company, with the CEO as chairman. They have a defined cadence for meeting and a clear mandate: evaluate what’s being built, approve or redirect projects, and set priorities.

A governance framework. A simple Red/Yellow/Green system: red means stop and get approval, yellow means proceed with caution, green means go. Owned by their IT and architecture lead, Carlos P, who walked the room through it and earned buy-in from the group.

Tool standards. Google Workspace as the default ecosystem. Claude permitted for justified use cases. This sounds simple, but TMS had never defined or agreed on this before. Now it’s in writing.

A learning funnel. With a committee in place, the rest of the organization now has somewhere to bring AI questions. Instead of everyone figuring it out alone, or not at all, there’s a known group responsible for guidance and decisions.

Why This Approach Works

We didn’t hand TMS a stack of documentation and wish them luck. Process adoption through complex documents doesn’t stick, especially at a company that’s never had formal AI processes to begin with.

What works is getting decision-makers in a room, forcing real choices, and walking out with something simple enough that team members will follow. A committee with three people and a monthly meeting is something that survives.

As outsiders, we also brought pattern recognition. We’ve seen how AI adoption plays out at other companies; what goes wrong when there’s no governance, what happens when shadow IT goes unchecked, what the real risks look like. TMS hadn’t seen that movie before. Being able to draw on those patterns helped move the room to decisions faster than an internal team working through it on their own.

Where TMS Goes From Here

The original goal, getting leaders to embrace AI and cascade it into their teams, is still the goal. The governance work was the prerequisite that had to happen first. Now that TMS has a committee, a framework, and agreed-upon tools, they have the foundation to start identifying and pursuing AI opportunities department by department.