Geisel Software, Inc.

95% of enterprise AI initiatives produced no measurable business value last year. The models weren't the problem.

MIT's Project NANDA looked at more than 300 enterprise AI initiatives. Despite tens of billions in investment, most stalled before delivering meaningful results. The common failure wasn't model performance. It was integration. Systems couldn't retain feedback, adapt to changing conditions, or hold up once they encountered real operational workflows.

The models worked. The deployments didn't.

In robotics and other physical systems, that gap gets even wider. Clean datasets become noisy sensors. Controlled environments become unpredictable ones. Suddenly you're working within hard latency budgets, handling edge cases, and building systems that have to behave correctly the first time, every time. A robot that collides with a pallet or a medical device that requires a recall doesn't get fixed with the next software update.

That's the problem forward-deployed engineering is meant to solve. It's not a new idea. Palantir introduced the term more than a decade ago. The model is simple: experienced engineers work alongside your team, on your hardware, under your operating constraints, and stay accountable through deployment. The people designing the solution are the same people responsible for making it work in production.

One finding from Project NANDA stood out: organizations working with external engineering partners were about twice as likely to succeed as teams relying solely on internal development.

The teams getting systems into production aren't necessarily spending the most. They're bringing in people who've already solved the kinds of problems that don't show up in a demo.

Brian Geisel breaks down what forward-deployed engineering actually is, how it differs from consulting or staff augmentation, and the signs that tell you when it's the right approach.

Link in the comments.

Perception gets the demos. The decision layer gets the postmortems.

Here's the thing that layer has to do, all at once: decide fast, decide in a way you can explain, and stay safe when it's working from a picture of the world that's incomplete. Each of those is manageable on its own. Together, in the same control loop, they fight.

Take safe-under-uncertainty first. The planner is acting on a fused estimate from sensors that disagree, with a confidence that's usually rosier than it should be, because nobody models the tails honestly. So the right move often isn't the one that looks best on the current picture. It's the one that keeps you recoverable if the picture turns out wrong. Plan for the expected case and bolt a safety check on afterward, and that's exactly the gap that bites you.

Now add fast. Not good average latency, worst case. A planner that's quick on average and ugly at the tail will blow the loop on the one cycle that mattered, and that's the cycle you'll be explaining later. The moment you harden the worst case, you're usually giving up decision quality to do it. That's the tradeoff, right there.

Now add explainable. When the safety review asks why it braked, "the model decided" is not an answer anyone signs off on. So you keep the decision logic inspectable on purpose, which constrains how much you can lean on a policy you can't trace. A layer you can't explain is one you can't certify, however good the numbers look.

None of these is hard in isolation. The engineering is that a real deployment demands all three in the same loop, at the same time, and they trade against each other directly. That's the layer where strong programs stall, usually in integration, usually later than they wanted.

Developers do not love engineering because they enjoy pressing keys.
They love understanding difficult problems, exploring trade-offs, and building elegant solutions.
That distinction matters as AI becomes part of everyday development.

A healthy AI culture should not simply maximize how much code gets generated.
It should protect the parts of engineering that create real value.

⌨️ Boilerplate, repetitive implementation, and routine transformations can often be automated.
🧠 System design, problem framing, and technical reasoning should remain visible and valued.
🛠️ Good engineering still depends on simplicity, judgment, debugging, modeling, and thoughtful trade-offs.
🔍 As generation accelerates, validation becomes more important, not less.

AI can increase output while quietly reducing ownership, creativity, and satisfaction.
If engineers spend their days prompting, checking, and correcting machine-generated work, productivity may rise while the craft deteriorates.

The goal should not be to preserve manual coding for its own sake.
It should be to use automation without removing the deep thinking that makes engineering meaningful.

Protect the craft.
Not the typing.

AI agents are becoming more capable.
They can modify repositories, execute commands, deploy infrastructure, and make changes across an engineering environment.

That creates a new problem:
We give AI agents more permissions to make them useful.
Then we discover that usefulness without containment is a production risk.

An engineering agent should never operate without a clearly defined blast radius.
Five controls matter:
🔒 Least-privilege credentials
Give the agent access only to the systems and actions required for the task.

📁 Repository and directory boundaries
Define exactly where it can read, write, and execute.

🧪 Sandboxed ex*****on environments
Test uncertain actions in isolated environments before they reach production.

⏸️ Approval gates for irreversible operations
Deployments, deletions, credential changes, and infrastructure updates should require explicit authorization.

🧾 Complete action and decision logs
Teams need to know what the agent changed, which tools it used, and why it selected a particular action.

The goal is not to prevent agents from acting.
It is to ensure that when they make a mistake, the consequences are limited, visible, and recoverable.
As software systems become more autonomous, agent containment will become part of secure architecture, not an optional safety layer.

Autonomy fails when decision-making depends on the cloud.
Robots, drones, and connected devices often have to choose what to do when the network is unavailable, intermittent, jammed, or simply too slow.

That decision has to happen on the platform.
Geisel Software builds the decision layer between perception and action:
Path planning for ground, aerial, and hybrid robotic systems
Behavior trees, state machines, and goal arbitration
Real-time autonomy for constrained edge compute
Fault detection, recovery behaviors, and degraded operation
Multi-agent coordination across distributed fleets

The difficult part is rarely the controlled demo.

It is what happens when sensors disagree, objectives conflict, compute resources tighten, obstacles appear unexpectedly, or the platform enters a state the original design never explicitly modeled.
In those conditions, the system still has to make a decision.
And in high-consequence environments, the wrong decision is not a minor inconvenience.
It can mean a collision, a missed objective, an aborted mission, or a platform stranded beyond an operator’s reach.

That is why we architect autonomous systems for failure, uncertainty, and real-world deployment from the beginning—not after the demo works.

Yes, vibe coding is real.
And yes, it can be a game-changer.
Turning an idea into a working prototype in minutes is powerful.
It speeds up experimentation.
It shortens feedback loops.
It helps more people build software faster than ever.
But speed is only half the conversation.

The other half is security.
AI-generated code can still introduce subtle vulnerabilities, weak assumptions, and patterns that fail at scale.
And when code moves from an LLM into production without scrutiny, the risks move with it.
The question is no longer whether teams should use these tools.
That decision has already been made.

The real question is:
How do we keep the speed without losing trust?
At Geisel Software, that means:
Trust, then verify
Treat AI-generated code as untrusted until it has been reviewed and tested.

Automate security early
Use static analysis, secret scanning, and dependency checks before risks reach production.

Understand the blast radius
Be especially careful with authentication, infrastructure, data pipelines, and other high-impact systems.
It also means prompting responsibly, protecting sensitive information, and making security expectations part of the development workflow from day one.
AI can increase velocity.
Security makes that velocity sustainable.

At Geisel Software, we believe teams can have both.
But only when vigilance grows alongside speed.
How is your team reviewing AI-generated code?

Physical AI is not just AI connected to a machine.
It is AI operating under real-world constraints.

A software model can be retrained after making a poor recommendation.
A physical system may have milliseconds to make a decision involving motors, sensors, control surfaces, medical equipment, or autonomous platforms.

That changes the engineering problem.

Latency becomes a system constraint
A control loop that responds too slowly may become unstable or unsafe.
Model accuracy is not enough
The system must still perform when sensors degrade, environments change, or inputs fall outside the training distribution.
Safety must exist outside the model
Deterministic limits, watchdogs, overrides, and fail-safe states must constrain what the AI is allowed to do.

The hardest Physical AI problems often appear between disciplines:
Hardware and software.
Simulation and reality.
Perception and control.
Model performance and system safety.

Successful teams treat Physical AI as a systems engineering problem from the beginning.

Because in the physical world, the model does not determine success.
The complete system does.
Read the full post on our blog!