The best part of our software are the people that build it.

Software can't ask the probing questions that reveal where an operation hurts, so we put engineers inside customer operations instead: shipping changes in hours, owning misses on the record, and deploying AI only where it acts on a measurable outcome.

The intent of software is to solve human problems. That sentence used to be obvious enough that nobody had to say it. The last 20 years of enterprise software turned it into something else: build a product, find the customers who fit it, scale the distribution. The product was the unit of value. The customer's actual mess was someone else's department.

That model worked when building software was hard. It is increasingly not.

A modestly capable team can stand up a container tracking dashboard in a weekend, and plenty have. The software is no longer the bottleneck. The bottleneck is everything around it: your TMS, the ERP with no API, the business rules that live in one import manager's head, the trust that must exist before your team will tell a vendor what is actually broken. None of that scales through code. All of it requires a human who can do the engineering and the conversation fluently.

Silicon Valley has a name for that human: the forward deployed engineer, a software engineer who works embedded inside a customer's operation instead of behind a product team. At Gnosis, we built the company around our own version of the role. We call them logistics engineers.

A logistics engineer scopes, builds, ships, and stays inside your operation.

A logistics engineer is a software engineer and a solutions engineer in one person, with the freight knowledge to be useful as either. They scope the problem, build the solution, ship it, and stay through the production issues. No handoff to a delivery team, no ticketing queue between you and the person who can change the code.

They are forward deployed in the literal sense: embedded in your operation. They sit in your Slack and Teams channels. They join your weekly touchpoints and working sessions. When your transload team walks through an invoice audit line by line, the engineer who built the audit is on the call, taking the feedback directly.

In an ordinary week, a logistics engineer will:

• Build integrations between the Container Lifecycle Management platform and your TMS, ERP, and reporting stack, and troubleshoot the ones already in production

• Sit in your operations meetings and hear problems described in your team's own language

• Carry your requirements into our product and carry technical answers back, so nothing gets lost in translation between an import manager and a developer

• Hold the operational context: which charge discrepancies should warn, which should hard-reject, which need a comment every time

Three things follow from that job description.

The code is built inside your constraints. There are no greenfield projects where the engineer controls everything. They build inside your systems, your data quality, and processes someone designed a decade ago.  

They speak both languages. Most of a logistics engineer's conversations are with import managers, transload teams, and analysts, not with other engineers. They can hear an operator describe a process and know which 15 data points it needs, and they explain what they're building in the operator's terms. The conversations are where the work gets shaped.

One person carries full context. That is the structural feature that makes everything else work, and it has a side effect that does a lot of back stage work: when the same person scopes and builds, they can't overpromise, because they know exactly what they're signing up to spend the next 2 months on.

The real problems only surface to a person your team trusts.

Software does what you tell it. It has no intuition, no hunch, no empathy, and it can't ask the probing question that reveals where an operation hurts. People, meanwhile, usually know they're in pain but can't name its source. It's hard to read the label from inside the jar.

The category of problems software solves are problems where humans fail, and that failure has a visceral pain to it. If you cannot tap into that pain, you cannot build the thing that relieves it.

The pain is rarely in the place the customer points to. They will tell you about the dashboard that is too slow. The actual problem is the 45 minutes they spend every morning reconciling data across three systems because the operator who built the original process retired in 2017. Getting from the first conversation to the second one takes someone the customer trusts enough to admit the second story exists.

You can be a brilliant surgeon and lose patients because you have no bedside manner. The mechanism is the same. If the customer does not feel safe with us, they will not show us where it actually hurts. They will give us the version of their problem that survives in a sales meeting. The version that survives in a sales meeting is the version software has already failed to fix. It is also the version every competitor's demo can already handle.

This is why curiosity is the moat. The kind of curiosity that makes a customer feel like the person across the table is genuinely trying to understand their world rather than fit it into a pre-built demo.

Curiosity also requires a posture. Wanting to solve a problem puts you in a different stance than wanting to close a deal. The sales cycle pressures the customer. People do not like being sold to and they cannot be vulnerable under pressure. The logistics engineer's advantage is that they show up to solve the problem, which is the only posture from which the truth comes out.

The value of software depends on what is at stake when it works. A tool that solves a low-stakes coordination problem is worth what coordination is worth. A tool that prevents a Fortune 500 BCO from missing earnings because their ERP could not reconcile is worth orders of magnitude more. The logistics engineer's job is to find the second kind of problem, the one with stakes the customer cannot fully articulate until someone they trust asks the right question.

This is what AI has not changed. The model is faster than ever. The pain is still located inside the customer. The path to the pain still goes through a human.

Operator feedback becomes shipped software.

On a working session with a national discount retailer, their transload team walked through our new invoice audit line by line and told us where the logic was wrong for how they operate. Carton-count discrepancies happen constantly in transload, so those should warn, not block. A cost-per-unit that violates the contract, including the min/max charge logic, should hard-reject and force the provider to resubmit. Miscellaneous charges should require a comment, every time.

The engineer building the audit was on the call, taking the feedback directly. The changes were ready for testing the next day. That loop, operator to engineer to shipped change, is the thing we'd point to if you asked what Gnosis sells.

An e-commerce fulfillment company we work with was wiring our webhooks into the database table that powers their internal reports, and their first configuration listened too broadly: close to 11,000 rows generated overnight, one for every field change, including timestamps shifting by seconds. The next morning, one of our engineers got on a call with their developer and restructured the listeners together: separate configurations for create and update events, scoped to the columns that matter, tested behind a feature flag before the production cutover, finished ahead of the developer's vacation the following week. Nobody filed a ticket. A person who understood both the webhook architecture and the freight data flowing through it answered, that day.

Every AI claim answers 2 questions: today or roadmap, inform or act

What does it do today versus on the roadmap, and does it inform a decision or act on one? Every AI capability we describe must answer both.

Today, in production: AI parses carrier invoices into structured, auditable line items, and automated audits approve or flag them against contract rates. When parsing gets an invoice wrong, a logistics engineer follows up on the specific errors by name, because the audit is only as trustworthy as its inputs.

On the roadmap, scoped with that same discount retailer: agentic dispute handling for demurrage and detention, catching vessel delays and last-free-day extensions and assembling the dispute before an analyst would have found the charge. It acts on a measurable outcome, dollars recovered, which is the standard any AI feature has to meet before we ship it. We say which side of the line each capability is on, out loud, before a customer commits.

Engineers who speak both freight and code are why customers stay.

Behind this approach is a track record of never saying no to a hard problem, and near-zero churn behind that. Both trace to the same source: people who know demurrage and API payloads in the same sentence. When something is infeasible, we say so, and then we find another way.

Plenty of vendors will sell you AI this year. Ask who answers when it misbehaves at 7 a.m. on a Tuesday, whether that person understands your freight, and whether they can change the code. Our answer to all 3 is the same person. The best part of our software is the people who build it.

Your first conversation with Gnosis Freight can include the logistics engineers who would build your solution. Bring the problem nobody has been able to fix and together we’ll figure it out.