Inspiration

As a developer I use agents in my workflow a lot - whether it be for coding or automating tasks. ie. using an agent to find me hackathons, find job postings, manage my calendar, consider system design constraints and create scoped plan that coding agents/sub agents do. Becoming ai-native has saved me a lot of time and let me focus on tasks with high opportunity cost. Dispatchers do 10 different tasks, handle incoming problems and work across multiple different software. Dispatchers can save a lot of time and money by using an agent native platform that lets them focus on the tasks with the highest opportunity cost while agents work on other tedious jobs.

What it does

Jarvis is an agent-native operating system for trucking operations. Instead of dispatchers jumping between load boards, fleet management systems, maps, documents, messaging tools, and spreadsheets, Jarvis gives them one interface where they can ask for an outcome and let agents coordinate the work.

A dispatcher can ask Jarvis to investigate a load, check the current route, account for traffic and remaining drive time, evaluate whether a delivery is at risk, compare alternative loads, or navigate directly to the information they need. Jarvis can then break the request into smaller tasks and delegate them to specialized agents.

We built the platform around several parts of a trucking operation:

Jarvis: the main interface for interacting with the system using natural language.
Agents: specialized agents and workflows for tasks such as load analysis, routing, driver operations, and monitoring.
Loads: brings load information, documents, operational context, and load-board opportunities together so agents can reason about which loads make sense instead of simply showing the highest-paying option.
Operations: provides a live operational view of vehicles, routes, traffic, geofences, and events so agents can reason using the same context a dispatcher has.
Logbooks: surfaces driver and trip information needed when making operational decisions.
Finance: gives agents access to the economic context behind a load so decisions can consider profitability instead of only distance or revenue.
Skills and Plugins: provide a way to extend what Jarvis can understand and do as new systems are connected.

The goal is not to replace the dispatcher. It is to remove the constant context switching and repetitive work around them so they can spend more time dealing with customers, drivers, exceptions, negotiations, and other high-opportunity-cost decisions.

How we built it

We built Jarvis as an agent orchestration layer on top of a trucking operations platform.

The frontend gives dispatchers a visual environment for loads, operations, agents, finance, logbooks, and system integrations, while a Python backend handles agent execution and operational workflows.

Instead of using one giant prompt, Jarvis works as an orchestrator. It interprets a dispatcher's request, determines what information and capabilities are required, and delegates work to the appropriate tools or specialized agents. This lets us build workflows where one request can involve multiple pieces of operational context rather than forcing the dispatcher to manually perform every step.

For example, a request about a delayed delivery can require information about the active load, current vehicle position, route, traffic, remaining drive time, delivery window, and alternative routing. Jarvis can collect that context and use it together before deciding what action to recommend or execute.

We also connected the platform to real-world trucking concepts and services including mapping and traffic data, load-board workflows, fleet-management data, documents, and communications. We used Mapbox for mapping and routing functionality and Twilio for our communication workflows.

A major part of the project was also building a simulation environment. This allowed us to reproduce events such as a truck moving along a route, delays occurring, detention events, rerouting, and delivery progression without needing a live fleet during the hackathon. That gave our agents a changing environment to observe and react to rather than a static dashboard.

Challenges we ran into

The hardest problem was making Jarvis feel like an actual agent rather than a chatbot sitting on top of a dashboard.

It is relatively easy to generate a response such as "this shipment may be delayed." It is much harder to give an agent enough structured context to determine why it is delayed, identify what systems it needs, choose the appropriate actions, execute them, and maintain state as the situation changes.

We also ran into challenges around agent latency. A dispatcher cannot wait a long time every time they issue an instruction, especially when the underlying workflow requires several tools or agents. We reworked parts of our execution flow so Jarvis could acknowledge a WorkRun in roughly 1.1 seconds while the deeper workflow continued executing.

Another major challenge was our simulation engine. Movement could not simply animate a truck between arbitrary coordinates; the truck had to progress along an actual route while operational events, traffic, ETA calculations, and agent decisions remained consistent with that movement. Getting those systems to share the same state required significantly more work than building the visual interface itself.

Finally, external integrations introduced real constraints. Communication providers, load boards, traffic providers, and fleet-management systems all expose different APIs and permission models. We had to design Jarvis so an unavailable capability would not cause the entire workflow to fail and so integrations could progressively be replaced with production systems.

Accomplishments that we're proud of

We're most proud that we moved beyond building a trucking chatbot and built the beginnings of an actual agent-native operating system.

Jarvis can reason across different areas of the application instead of being isolated to a single page. It can understand a higher-level request, use operational context, invoke specialized capabilities, and coordinate workflows across the system.

We also built a simulation where the agents operate against changing conditions. Trucks move, routes change, delays can occur, deliveries progress, and operational events give the agents something meaningful to react to. This made it possible to test the system much more realistically than simply feeding an LLM predetermined examples.

We spent a significant amount of time on reliability as well. Our autonomy and voice test suite reached 24 passing tests, and we reduced the acknowledgement latency of our agent WorkRun flow from roughly 3.4 seconds to about 1.1 seconds.

Most importantly, we ended up with a system where adding AI did not mean adding another chat window. The agent is connected directly to the workflows and operational context of the product.

What we learned

The biggest thing we learned is that making software "agentic" is mostly a systems-design problem.

The model is only one component. An effective operational agent needs tools, permissions, state, context, observability, failure handling, and clear boundaries around what it can and cannot do. Giving a model more prompts does not solve those problems.

We also learned how important it is to separate an intent from the exact sequence of actions required to accomplish it. A dispatcher should be able to say something like "handle this delay" rather than knowing which five APIs and three screens are involved. The agent should determine the workflow from the available context.

At the same time, agents should not autonomously do everything. Some actions are safe to execute automatically, some should produce a recommendation, and others should require human approval. Designing that boundary is especially important when an agent interacts with drivers, customers, financial information, or external systems.

Finally, we learned that the best interface for an agent isn't necessarily chat. Sometimes Jarvis should answer a question. Other times it should navigate the dispatcher to the right screen, update the UI, trigger a workflow, surface an exception, or quietly perform work in the background. The interface should depend on the task.

What's next for Jarvis

Our next step is turning Jarvis from a set of predefined agent capabilities into a more extensible agent platform.

Today, software agents are usually limited by the tools engineers explicitly build for them. As Jarvis grows, manually creating a new tool for every feature would eventually become its own bottleneck.

We want Jarvis to be able to recognize when it cannot complete a requested workflow, inspect the capabilities and APIs available to it, and propose the tool or workflow it would need. An engineer or operator could review and approve that capability before it becomes available to the system. Over time, this would allow Jarvis to expand what it can do without requiring every new workflow to be manually orchestrated from scratch.

We also want to connect deeper into fleet-management systems, load boards, TMS platforms, telematics, communications, accounting systems, and carrier documents so Jarvis has a unified operational model of the fleet.

Eventually, we see Jarvis becoming the interface between a trucking company and its software stack: dispatchers specify the outcome they want, specialized agents coordinate the work, and humans remain in control of the decisions that actually require them.