Beyond Agent-Washing: The Engineering Principles Behind Production-Ready AI Agents

An AI agent is not defined by how intelligently it talks. It's defined by what it's trusted to do.

Give a language model a chat window, and you have an interface. Give it access to production APIs, identity, business logic, memory, and the authority to execute actions on your behalf, and you have something categorically different: a new kind of software actor, one that can read your data, write to your systems, and make decisions faster than any human reviewer can watch in real time.

That distinction is where most of the industry's "agent" marketing quietly falls apart. And in 2026, the gap between marketing and engineering has become measurable. AvePoint's third annual State of AI report, based on 750 global IT leaders across financial services, healthcare, and government, found that 88.4% of organizations experienced at least one AI agent–related security breach in the past twelve months, with data leakage and manipulation by untrusted input as the two leading causes (AvePoint, State of AI 2026). Separately, McKinsey's 2026 AI Trust Maturity Survey — fielded across roughly 500 organizations between December 2025 and January 2026 — found that only about 30% of organizations have reached a mature level of governance and agentic controls (McKinsey, State of AI Trust 2026). Adoption has outrun governance by a wide margin, and the bill is starting to come due.

I spent several hours this year with Ted Kornish, CTO of Gravity, a platform built for corporate sustainability and emissions reporting, to press on a narrower question than "does your product have an agent?" The question was: what has to be true, architecturally, before a system earns the word at all? Kornish's answers are the evidence in this piece, not the subject. Gravity is a useful case study — a production system operating in a regulated domain where a wrong answer can end up in front of a regulator — but the principles below are my own synthesis of what separates a genuine enterprise agent from a chatbot wearing a lanyard.

The Five-Question Agent Test

Before accepting any vendor's "AI agent" claim — including Gravity's — I now run it through five questions:

1. Can it execute actions, not just generate recommendations?
2. Can it compose multiple capabilities to accomplish a goal it wasn't explicitly scripted for?
3. Does it operate through the same business logic and APIs your human users already use?
4. Can every action it takes be attributed to a specific identity and audited after the fact?
5. Can a potentially destructive action be previewed, validated, and approved before it commits?

If the answer to the first three is no, you're looking at an AI feature — useful, maybe, but bounded and predictable. If the answer to four and five is no, you're looking at an AI feature that probably shouldn't have production access yet, regardless of how capable its model is.

Kornish's version of this test, from our conversation, is the cleanest I've heard a vendor articulate unprompted: "If you can list every task it handles, it is a feature. If you can't because it can compose a wide variety of platform capabilities, it's an agent." Ask a vendor to enumerate every task their agent handles on a sales call. Most stall out after three or four items, and the stall itself is diagnostic — a genuine agent's capability surface resists a clean list because it's compositional, not because nobody documented it.

Why API-First Architecture Is the Real Moat

Here's the engineering claim underneath the marketing claim, and it's the one I'd stake the rest of this article on.

Most enterprise platforms were built UI-first, with an API bolted on afterward as a partial mirror of what the interface already does. That ordering was fine for a decade of humans clicking buttons through a screen. It becomes a structural liability the instant an agent needs to act with the same range a human employee has — because if the API was never built to be complete, an engineering team is stuck choosing between two bad options: let the agent do less than a human could, or build a second, parallel execution path just to give it a fighting chance. Neither ages well. The first caps the agent's usefulness permanently. The second means maintaining two versions of every business rule indefinitely, with near-certainty that they drift apart in some edge case nobody thought to test.

Gravity sidestepped that fork by never building a second path:

"We never built a separate 'agent version' of Gravity with its own private set of functions. On the read path, the agent calls the exact same HTTP API our product UI calls... On the write path, there's a service layer that provides one execution path for any given action, one place validation and business rules live, and one codebase to test and maintain instead of two."

The architectural implication here is bigger than agent convenience. Once an agent becomes just another API client, the API itself becomes part of the agent's safety boundary. Authentication, authorization, idempotency, validation, rate limiting, transaction handling, and auditability stop being secondary infrastructure and become prerequisites for autonomy. That reframes the first question an engineering team should ask when evaluating agent readiness. It isn't "which model should we use." It's closer to: can an untrusted software actor safely exercise the application capabilities we already have?

Kornish's line on this is worth sitting with: "An agent is really just a new kind of caller on an API that was already capable; if that API doesn't exist, there's nothing for the agent to stand on." That's not a race to fine-tune the flashiest model. It's a race to have quietly built a serious, typed, permissioned API years before anyone had a reason to think an LLM would ever call it — and most incumbent platforms already lost that race without knowing it, because the decision was made a decade ago by a team with no reason to think about agents at all.

The hardest part, in his account, isn't reads. Reads are comparatively low-stakes; nothing breaks if a summary is slightly stale. Writes are a different category of problem entirely, because most enterprise write paths aren't atomic — you're editing individual records one at a time, and the only thing worse than writing the wrong data is writing partial data, which leaves the system in a state nobody designed for and nobody can cleanly roll back. That's the real, unglamorous reason so many "enterprise AI agents" on the market today are read-only interfaces wearing an agent's branding: atomic writes are hard, and most legacy write paths were never built for it.

What This Looks Like In Production

Abstract architecture arguments are easy to nod along to and hard to actually picture. Here's a concrete workflow, reconstructed from how Gravity describes its own execution path for a regulatory reporting task:

User:
"Prepare this quarter's emissions report and flag anything
that needs my attention."

    ↓

Agent — parses the objective, checks its ~85 versioned skills
    for the relevant reporting operations (progressive disclosure:
    hand the model what's relevant to this step, not everything)

    ↓

APIs — retrieves source data through the same HTTP API
    the product UI uses, governed by the same permissions

    ↓

Deterministic Engine — runs the actual emissions math;
    the model never touches the calculation itself

    ↓

Validation — checks for anomalies, missing fields, and
    inconsistencies against prior filings

    ↓

Agent — drafts the report narrative, cites every source
    and every calculation it pulled from

    ↓

Human — reviews the staged preview, approves or rejects
    
    ↓

Production — the report commits; the full trace is retained

The model's job in that chain isn't the arithmetic — it's everything around the arithmetic. Sourcing the right document, filling a gap, matching the tone of last year's filing so the report reads as one continuous document rather than two authors stitched together. The ground truth stays boring and deterministic. The model's intelligence gets spent on the parts that used to consume a compliance team's entire week.

Agent vs. Copilot vs. Automation

The three categories get flattened together constantly, and the flattening is exactly what lets the word "agent" get retrofitted onto anything with a chat box.

These categories overlap in practice more than the table suggests, and that's worth saying plainly: the meaningful distinction isn't the marketing label a vendor chose; it's the system's actual degree of autonomy, compositionality, and execution authority.

The Five Layers, and Why They Aren't Interchangeable

Looking at Gravity's stack alongside broader enterprise agent design patterns, a consistent structure emerges — five layers, each dependent on the one below it, each a distinct point of failure if it's missing or built poorly.

Layer 5 — Governance         Identity · audit · human approval

                ↑

Layer 4 — Execution Layer    The API business logic actually runs through

                ↑

Layer 3 — Domain Skills      Versioned, tested, maintained like production content

                ↑

Layer 2 — Planning & Reasoning   Goal decomposition, task checklists

                ↑

Layer 1 — Foundation Model   Replaceable, increasingly commoditized

My interpretation of this stack is that the layers are not equally substitutable. The foundation model is replaceable — most serious vendors have access to roughly the same handful of frontier models, and Layer 1 is where competitive advantage is evaporating fastest. The planning harness can evolve; skills can be versioned and rolled back like any other content. But the execution and governance layers are much harder to swap out, because they encode an organization's actual operating rules — its permission model, its validation logic, its regulatory obligations. That suggests the durable competitive advantage in enterprise agents sits lower in the stack than most of the AI discourse right now assumes. Everyone is fighting over Layer 1. Most of the actual failures live in Layer 4 and Layer 5 — the parts that don't show up in a demo.

Kornish's own framing on where the industry is spending its engineering effort was more candid than I expected from a CTO on the record: "we're very bitter-lesson-pilled over here: increasingly, the agent is just a model and a thin harness... the system prompt is getting shorter over time as the models internalize more capabilities." The elaborate custom orchestration graphs that dominated agent architecture discussions for the last two years are being displaced — thinner harnesses, base models absorbing more of that responsibility natively, and open protocols like Model Context Protocol doing at the ecosystem level what bespoke orchestration used to do inside one vendor's codebase.

My Technical Take: The Agent Is Only As Strong As Its Execution Boundary

Here's the architectural lesson I actually take from this, stated plainly and separately from anything Kornish said: an enterprise agent shouldn't be designed as an intelligent application sitting on top of an existing platform. It should be designed as an execution client operating inside a security and transaction boundary that already exists independently of it.

That distinction sounds pedantic until you trace what happens when it's missing. If a model can reason but can't safely execute, it's a copilot — useful, bounded, not what we're talking about in this piece. If it can execute but bypasses the platform's own authorization and validation logic to do so, it's not an agent, it's a security liability wearing an agent's branding. If it can execute safely but nothing about that execution is observable after the fact, it's operationally untrustworthy regardless of how well it performed in the room. And if it clears all three of those bars but is never re-evaluated as the model, the skills, and the surrounding data shift, its reliability will decay quietly, without anyone noticing until an incident forces the question.

That chain leads to a fairly simple principle, and it's the one I'd want any engineering team to write on a whiteboard before they start: the model should decide what to attempt. The platform should decide what is allowed to happen. Collapse that distinction — let the model's judgment double as the authorization check — and you don't have an agent. You have a very articulate way of bypassing your own access controls.

I'd formalize this as the agent execution boundary — the layer, architecturally distinct from the model itself, where a proposed action gets checked against identity, authorization, validation, deterministic logic, and (ideally) a dry run, before it's ever allowed near production data:

                          USER INTENT

                               │

                               ▼

                    ┌─────────────────────┐

                    │      AI MODEL       │

                    │      Reason/Plan    │

                    └──────────┬──────────┘

                               │

                               ▼

                    ┌─────────────────────┐

                    │    AGENT SKILLS     │

                    └──────────┬──────────┘

                               │

                               ▼

                  ┌─────────────────────────┐

                  │    EXECUTION BOUNDARY   │

                  │                         │

                  │        Identity         │

                  │      Authorization      │

                  │       Validation        │

                  │   Deterministic Logic   │

                  │         Dry Run         │

                  │          Audit          │
  
                  └────────────┬────────────┘

                               │

                         Human Approval

                               │

                               ▼

                        PRODUCTION DATA

The model should never be the final authority on whether an action is valid. It proposes; the execution boundary determines whether the proposal is permitted, reversible, and safe to commit. Everything Gravity described to me — the shared API surface, the dry-run engine, the staged preview, the permission-inherited approval gate — is one implementation of that boundary. It isn't the only valid implementation. But any architecture that skips having one, in favor of trusting the model's own judgment about what's safe, is building on a foundation that will eventually fail in a way nobody can cleanly attribute afterward.

Deterministic vs. Probabilistic Is the Real Design Boundary

The design decision that matters most isn't "AI versus not AI." It's probabilistic versus deterministic execution, and a serious architecture puts uncertainty exactly where judgment is valuable and removes it everywhere correctness is mandatory.

Kornish didn't hedge when I asked him where Gravity draws that line: "Emissions math always runs through our deterministic calculation engine, no exceptions, because a regulator does not accept 'the model recalculated it slightly differently this time' as an answer." His broader rule generalizes well past sustainability reporting into any regulated domain — healthcare, finance, insurance: where correctness counts, use a calculator; where you need judgment, use a person; where approximate correctness is fine, AI saves time and money.

The model can decide which document to inspect, which skill to invoke, and how to explain an anomaly in plain language. It should not silently become the source of truth for a number that could have been deterministically reproduced. Any output that could become evidence in an audit, a regulatory filing, or a legal dispute should trace back to a deterministic calculation — never a model's best guess, no matter how good that guess usually is. "Usually" is not a standard a regulator will accept, and it shouldn't be a standard engineering teams accept for themselves either.

What Gravity Gets Right — And Where I'd Push Back

To be specific about what Gravity's architecture actually demonstrates, rather than just asserting it's good: API-first execution with no parallel agent path, a deterministic calculation engine that the model cannot override, permission inheritance instead of a separate AI policy layer, staged writes with mandatory human approval, persistent task state across sessions, a visible reasoning trace and tool-invocation history, and continuous evaluation fed by production telemetry rather than a one-time launch gate.

Gravity isn't interesting because it has an AI agent. What's interesting is the infrastructure surrounding the agent — the model is one component of the system; the API, the identity model, the deterministic engine, and the governance layer are what determine whether that model can be trusted to act in the real world at all.

That said, don't mistake this for an endorsement without edges. A few things I'd want to see stress-tested before calling any system like this "solved," Gravity included: how the skill-versioning process holds up under a genuinely adversarial red-team exercise, not just replay against known scenarios; whether the "agent inherits operator permissions" model actually closes the gap on authorized-but-unintended actions (more on that below); and how the observability stack performs under a long-running, multi-day task where context has had real time to drift. None of these are unique to Gravity. They're unresolved for the industry broadly, which is exactly why they're worth naming instead of glossing over.

Identity Is the Security Boundary — But It Isn't the Whole Boundary

This is where I'd ask security-minded readers to slow down, because the industry's threat model for agents is still catching up to what's actually being deployed in production right now.

Kornish's framing — treat the agent as a new employee with its own login, not a master key that opens every door in the building — maps directly onto zero trust: never assume implicit trust from network location or system role, verify explicitly on every call, grant only the minimum privilege the task requires. "Every action carries the operating user's identity through the entire call chain," he told me, "so when the agent hits our API, it's authorized exactly the way that user would be, not under some elevated service account." Permissions get recalculated on every request rather than cached at login — cached permissions are exactly the kind of stale-state bug that turns into an incident report months after the access was actually revoked.

From a security engineering perspective, this changes the traditional question of "what can the agent access" into a more useful one: under whose authority is this specific action being performed? That distinction matters because it should follow the action through the entire call chain, not just the login event.

But identity and least privilege, however well implemented, are necessary and not sufficient — and 2026 has produced hard evidence of exactly where that gap sits. In June 2025, researchers at Aim Security disclosed a zero-click prompt injection against Microsoft 365 Copilot, later assigned CVE-2025-32711 with a CVSS score of 9.3 and nicknamed EchoLeak. A single crafted email, no user interaction required, and Copilot followed hidden instructions embedded in the email to pull data out of OneDrive, SharePoint, and Teams (Beam AI, 5 Real AI Agent Security Breaches in 2026). The exploit didn't need a broken permission model. Copilot was, in a narrow technical sense, doing exactly what it was authorized to do — retrieve and summarize data the user could already access. It was the intent behind the action that was compromised, not the authorization.

That's the distinction the OWASP GenAI Security Project formalized when it published the Top 10 for Agentic Applications in December 2025, ranking Agent Goal Hijack as ASI01 — an attacker redirecting an agent's objective through content it reads, rather than code it runs, so the agent pursues the attacker's goal while believing it still serves the user's (Cycode, OWASP Top 10 for Agentic Applications 2026). There's an important line between authorization failure and intent failure. Traditional security controls are built to prevent unauthorized actions. Agent security has to address a class of failure traditional AppSec never had to model: an authorized action performed for an unauthorized purpose. A compromised document can convince an agent to delete a record the operating user genuinely has permission to delete. The API correctly authorizes the request. The system is still compromised.

Simon Willison's "lethal trifecta" is the cleanest mental model I've seen for when this actually turns dangerous: access to private data, exposure to untrusted content, and the ability to communicate externally. None of the three legs is a vulnerability in isolation. It's the combination that creates the exposure — an attacker slips an instruction into content the agent will process, the agent executes it, private data leaves the perimeter (Getia Consulting, AI Agent Security 2026). This isn't a theoretical framing anymore. Check Point Research documented a single operator combining Claude Code and GPT-4.1 to breach nine Mexican government agencies between late December 2025 and mid-February 2026, converting roughly 1,088 typed prompts into more than 5,300 AI-executed commands and exposing on the order of 400 million records — tax filings, civil registry, patient, vehicle, and electoral data (awesome-ai-agent-attacks, GitHub). That incident wasn't a prompt injection against a victim's agent — it was an attacker using agentic tooling as their own offensive platform — but it's a preview of the asymmetry defenders are up against: the same architecture that makes an agent useful for legitimate multi-step work makes it useful for an attacker's multi-step work too.

The supply chain is its own exposure. In March 2026, a malicious package sat live on PyPI for roughly three hours — the compromised LiteLLM release, which serves as the model gateway for CrewAI, DSPy, Microsoft GraphRAG, and a long list of other agent frameworks — during which roughly 47,000 downloads occurred, pulling a backdoored autonomous attack tool in alongside the update (Help Net Security, June 2026). That maps to ASI04 in OWASP's taxonomy — agentic supply chain vulnerabilities — a category that barely existed as a named risk eighteen months ago.

This is why identity propagation, least privilege, and audit trails are necessary but not sufficient on their own. Agent security also needs constrained tool semantics, confirmation boundaries on irreversible actions, data provenance the agent can actually answer for, and evaluation against adversarial instructions as a standing practice, not a pre-launch checklist item.

Observability as an Accountability Mechanism, Not a Debugging Aid

I'd push this argument one step further than the industry currently takes it: an agent's execution trace should be treated as a first-class security artifact, not an engineering convenience.

A traditional distributed trace tells you where a request traveled. An agent trace needs to answer a different set of questions — why the system selected a given tool, which identity authorized the action, what data informed the decision, what parameters were supplied, what the tool returned, and whether a human actually approved the resulting write. Gravity's implementation — a visible execution checklist that doubles as a timeline, a reasoning trace per step, full tool-invocation history, and a staged preview of every proposed change before commit — is the same instinct that produced distributed tracing and OpenTelemetry in cloud-native infrastructure a decade ago: a system too complex to reason about from the outside has to narrate its own behavior from the inside, continuously, or nobody downstream trusts it under real load. That reframing — trace as accountability mechanism rather than debugging tool — is, in my view, the more consequential shift, because it's what turns an incident review from forensics into something closer to a routine audit.

The Hard Problems That Remain

None of the above should read as "solved." The honest list of what's still genuinely unresolved, industry-wide, in mid-2026:

• Prompt injection, both direct and indirect, remains structurally difficult to fully close — OWASP's own 2026 LLM Security research put the year-over-year surge in injection attempts at 340% (AI Magicx, April 2026).
• Memory poisoning — a persisted context corrupted so a later, unrelated task inherits false assumptions — is now its own OWASP category (ASI06) and doesn't map cleanly onto any pre-LLM threat model.
• Authorized-but-unintended actions, the EchoLeak pattern, aren't fixed by permission inheritance alone.
• Long-running task failures and context drift over multi-day agent sessions are still mostly evaluated in demos, not adversarial production conditions.
• Skill and harness regressions can silently degrade a capability customers were actively relying on, which is why versioning and rollback matter as much for skills as for any other production code.
• Evaluation at scale — proving an agent's judgment holds up across the long tail of messy, real scenarios rather than a fixed benchmark set — remains closer to an open research problem than a solved engineering one.

The goal with each of these isn't to eliminate the risk outright. It's to make it observable, bounded, testable, and recoverable — which is a materially different, more honest bar than "safe."

My Framework for Evaluating Enterprise Agents

After going through Gravity's architecture in this level of detail and cross-referencing it against the broader 2026 threat and adoption data, I'd reduce production readiness to seven questions:

1. Agency – Can the system independently execute multi-step objectives, not just suggest them?
2. Compositionality – Can it combine capabilities it wasn't explicitly wired into a fixed workflow to perform?
3. Execution – Does every action pass through the same validated business logic a human user would hit?
4. Identity – Can every action be attributed to a specific principal, recalculated per call rather than cached?
5. Determinism – Are correctness-critical operations owned by a deterministic system, not a model's best guess?
6. Governance – Can risky mutations be previewed, validated, approved, and audited before they commit?
7. Evaluation – Can the system demonstrate its behavior stays reliable as models, skills, and scenarios keep shifting underneath it?

If an agent fails several of these, improving the model is very rarely the first engineering problem worth solving.

Where This Is Headed

Kornish's predictions for the next three to five years weren't flashy, which is exactly why I'd take them seriously. Scope stays the whole story — agents confined to what they were demoed on keep losing ground to agents that can operate across an entire platform, the same pattern that played out when narrow point solutions gave way to platforms in every other software category. Vendors without an API-first foundation fall further behind every year, because that kind of scope isn't something you retrofit after the fact. Gartner's own projection points in the same direction: 40% of enterprise applications are expected to embed task-specific AI agents by the end of 2026, up from under 5% in 2025 (Paul Okhrem, Enterprise AI Agents Adoption Statistics 2026). And observability finishes its transition from differentiator to baseline expectation, tracing the same arc logging and monitoring took in cloud infrastructure roughly a decade ago.

The industry's conversation about enterprise AI has spent the last few years almost entirely on model capability. The next phase is being decided somewhere else — in the API surface, the identity model, the deterministic core, and the governance wrapped around every write. That's not a glamorous place for the conversation to move. It's also the only place it was ever going to survive contact with a regulator, an auditor, or an attacker.

I conducted this interview with Ted Kornish, CTO of Gravity, specifically to understand how these architectural questions are being resolved inside a production system operating in a regulated domain. His platform is the case study here; the analysis and framework above are my own.