Why we're looking at this
Most “AI features” we review are a chat box wired to a model, sitting next to a traditional CRUD application. That's not what we mean by agent-native. We're studying systems where the agent is the primary interface to the underlying capability — tool calls, memory, and orchestration are core architecture, not an add-on. Our own build of Physiolaxy and our engagement with Upfreq Robotics are both live test cases for this thesis.
What we're seeing
- A consistent split between the reasoning layer (the model deciding what to do) and the execution layer (the harness that actually calls tools, holds state, and enforces limits) — conflating the two is the most common failure mode we see in early-stage agent projects.
- Systems that treat tools as first-class, typed interfaces — increasingly via MCP servers — recover from tool failures far more gracefully than systems with ad hoc function-calling glue code.
- The teams shipping reliably almost always have an explicit policy or approval layer between “agent decided to act” and “action executed,” even when that layer is thin.
Open questions we're still chasing
How much of the orchestration layer can be generic versus how much has to be rebuilt per domain? Our early answer, from building Physiolaxy's assessment engine and separate multi-agent orchestration work, is that the harness pattern generalizes far more than the domain logic does — which is exactly why we've built dedicated agent harness engineering into our practice rather than rebuilding it fresh for each client.