Build Your Own vs. Managed Agents: Know Where the Walls Are

A couple of weeks ago I wrote about picking an agent framework and landed on PydanticAI, because I wanted to stay cloud-agnostic. Everything in that post sits on one side of a line. PydanticAI, LangChain, Strands, Marvin. You write the loop or you configure someone's library, but the agent runs in your process, on your machine, in code you can read.

So in September I went and looked at the other side. I built a trading intelligence system with Cortex Code, Snowflake's coding agent, now branded CoCo. Five free data APIs, 22 dbt models, 13 analytics tables, four semantic views, four Cortex Agents, a Cortex Search service over SEC filings, a Streamlit dashboard. Thirty-seven prompts, 382 messages, six days.

The spectrum runs from least control and most features to most control and fewest features:

• Enterprise data science platform. Agents are platform objects, governed by the platform.
• Managed agentic workflows. Orchestration provided, steps declared.
• Managed agent applications. Hosted apps with agents inside.
• Notebooks. Interactive, you hold the loop.
• Agents and custom harness. Your harness, your tools, someone else's model.
• Build your own solution. Your loop, your orchestration, your evals, your weights.

My framework post lived entirely in the right-hand third. So I took the questions I ask of a framework and asked them of a platform instead.

How much does it hide? Everything. The loop, tool selection, planning, thread memory. On the managed end that's the pitch, not a flaw. You're paying not to own it.

Can I change models, and does it quietly tie me to one cloud? No, and yes. I asked which models my agents were running and got: auto-selected by the platform, "currently routes to Claude/GPT family." I wrote about Strands that "it's easy to end up more committed to one cloud than you meant to be." A warehouse is stickier than a cloud, because your data is already in it.

How does a risky tool get stopped? The managed end wins this one, and it isn't close. More on that below.

Can I test without paying for model calls? No. PydanticAI ships a test model so CI runs without an API key. On a platform every path runs through the platform's compute.

Does it get along with the rest of my stack? Partly. My dbt models are portable, because dbt is a standard with many runtimes. My semantic views are semi-portable. My agents aren't portable at all.

Two of those have no good answer on the managed end. That's a price, not a verdict.

I only built on one platform, so I want to be careful about which parts generalize.

Specific to Snowflake:

• CREATE AGENT as DDL. The agent is a first-class database object, created and described like a table or view.
• Semantic views as the tool interface. The agent's tools are database objects, not functions.
• Cortex Analyst for text-to-SQL and Cortex Search for retrieval, which indexed my SEC filings with snowflake-arctic-embed-m-v1.5 without my picking an embedding model.
• RBAC inherited from the warehouse.
• Warehouse credits and auto-suspend as the cost model.
• The vocabulary: .agent.yaml, SKILL.md, the cortex CLI, $skill-name invocation, /plugin:command suites.

The general pattern, which isn't Snowflake's doing:

• A declarative spec plus a managed runtime. You describe what the agent may do. The platform owns the loop.
• Convergence on the same components. Reporting on AWS, Microsoft and Google suggests all three now ship a runtime, memory, a tool gateway, identity, observability and governance under different names: Bedrock AgentCore, Microsoft Foundry, Google's Gemini Enterprise Agent Platform.
• Binding to the parent platform's identity stack. That's what makes the governance good, and it's what makes leaving hard. Same property.
• The provider choosing or routing the model.
• Artifacts living in the control plane rather than your repository.
• No portable spec exists. There's no agent equivalent of a container image. Nobody has defined one, and as far as I can tell nobody's trying.

Treat the cross-vendor part as directional. Most of what's written about it is vendor-comparison blogging, and the names keep moving. Azure AI Foundry became Microsoft Foundry in January. Google retired the Vertex AI branding at Cloud Next this year.

This took me most of a week to see, and it's the thing I'd want someone to take away.

When you build your own, there's no separate control plane. Your repository is the control plane. The agent definition, the tool allow-list, the approval rule, the model string, the eval suite: all of it is code, in version control, next to the thing it governs. The data plane, where the work happens, is whatever process you're running. The two are collapsed, which is why it feels like there's only one.

On the managed end they separate, and they don't separate evenly. The data plane you can see. Queries run, models answer, compute burns. The control plane, where decisions about your agent get recorded, moves into the vendor.

That's the real migration. Not "my code now runs on their servers," but the place where my agent is defined, versioned, governed and routed is no longer a place I own. This is a general distributed-systems idea, not a data-warehouse one. Kubernetes has it. Networking has it. Agents arrived at it recently and nobody announced it.

Read that way, a lot of small annoyances turn out to be one thing:

• My agent specs went to /tmp because my disk was never the control plane. It was a staging area. That's the architecturally correct place for a file whose destination is someone else's registry. The default was telling me the truth and I read it as a bug.
• Model routing changes without a diff in my repository, because routing is a control-plane decision and the control plane is theirs.
• "No portable spec" really means "no export format for control-plane state."

The extension surface is made of exactly the formats you'd pick if portability mattered. Skills are SKILL.md: markdown with YAML frontmatter, a name, a description, a body of plain instructions. Agents are .agent.yaml. Text files. They diff cleanly. They live happily in git.

Open one, though. The frontmatter is generic. The body isn't. It references the cortex CLI. It invokes other skills as $skill-name. It exposes slash commands as /plugin:command. It names semantic views, search services, RBAC roles. A plugin stub on my laptop right now describes its own workflow entirely in terms of cortex plugin enable and a /blueprints:* command suite.

So the file moves and the meaning doesn't. No DRM, nothing encrypted, no export refused. You can copy everything out, push it to GitHub, read it on a plane, and nothing will execute it except the runtime it was written for. The capture is in the vocabulary, not the container.

That's a wall. It's worth seeing clearly before you decide whether to live behind it.

Concretely, with my four.

They exist as Snowflake objects. DESCRIBE AGENT TRADING_DATA.ANALYTICS.TRADING_ASSISTANT works. I can pull the YAML back down. And then what? No runtime anywhere reads an agent spec whose tools are semantic views, whose planner is a managed loop, and whose retrieval is a managed search service. Exporting the file doesn't export the agent. The agent was never the file.

If I moved warehouses tomorrow, the dbt models would come with me. The semantic views would need rewriting. The agents would need rebuilding from scratch in a different paradigm.

Here's the detail that stopped me. Late in the build I went looking for the agent definitions and couldn't find them. They'd been written to /tmp during deployment and pushed straight to Snowflake.

/tmp/trading_assistant.agent.yaml
/tmp/risk_advisor.agent.yaml
/tmp/filing_analyst.agent.yaml
/tmp/market_coach.agent.yaml

The source of truth was the warehouse. My laptop had nothing. I had to ask for them to be pulled back down and saved next to my dbt models.

Now the part I didn't expect to write.

I went in skeptical and came out thinking that for a lot of teams, the managed end is the correct answer, and not as a compromise.

Authorization you didn't have to build. My agents inherited RBAC from the warehouse. An agent can't read what the person asking can't read, and I wrote zero lines to make that true. If you've ever tried to build this yourself, with a framework agent holding a service credential and you hand-rolling row filters in tool code, you know it's the part that keeps you up. In my framework post I said to keep the approval rule and the tool allow-list in your own code, because no framework knows which of your tools can cost somebody money. That advice still holds on the right-hand side. On the left, the platform genuinely does know, because it's the same system that already knows who you are.

The data doesn't leave. No egress to an API you have to vet, no copy of customer records in a vector store someone has to inventory. If you work anywhere with data residency rules, that one fact can decide the whole question before anyone discusses developer experience.

Audit comes free. Agent queries land in the same query history as everything else. One place to look, one retention policy, one export for the auditor.

One security review instead of five. This gets underrated by engineers and never by anyone who's been through procurement. Framework, runtime, vector store, secret manager, hosting: that's five vendor reviews, five contracts, five renewal cycles. Or it's an addendum to a contract you already have.

Nobody has to become a platform team. A small data team can ship a working agent without taking on a container to patch, a secret store to run, or a pager rotation. If you've got two data engineers and no platform engineer, "build your own" isn't a purer choice, it's a second job.

Set that against what you give up: naming your model, carrying your agents out, and keeping the approval rule in code you own. For an internal analytics agent over governed data, that trade looks pretty good. For work where you have to defend a number six months later, or where the thing has to run in three clouds, it doesn't.

Six days in I suspended everything and asked CoCo to explain the $9.08 in my cost management center. It queried the usage tables and came back with 4.80 credits.

Four managed agents accounted for 0.13 of those credits. About twenty-five cents. The warehouse sitting next to them accounted for nearly all the rest, and almost all of that was idle: a five-minute auto-suspend and a one-minute minimum billing increment meant every scattered query woke the warehouse for six billable minutes. On the busiest day, five Streamlit executions consumed 47.8 minutes of warehouse time while 1,689 SELECT queries consumed 4.5.

The credits and auto-suspend are Snowflake's. The shape isn't. On any managed end you're buying proximity to compute, and the compute is the cost model. The agents are a rounding error, which is worth knowing before anyone optimizes the wrong thing.

Not "how much control am I trading for features." Better questions:

• If this platform doubles its price in eighteen months, what do I carry out?
• Can a colleague read my agent without credentials to my account?
• Can I reproduce last quarter's answer, including which model produced it?
• Do my specs land in my repository by default, or in /tmp?
• Which layer of my stack is a standard that survives the move, and which layer is vocabulary?
• And the one that trumps the rest: does this data have rules about where it can go?

If the answer to that last one is yes, start on the left and make the right-hand side argue its way in. If you're building something you'll need to defend, reproduce or move, start on the right.

There's also a middle path I didn't take and would next time, close to what Thoughtworks recommends for AgentCore. Use the managed runtime for the production concerns it's good at, like session isolation, identity, governance and observability. Keep the orchestration logic in a framework you own. Rent the data plane, keep the control plane. You give up some integration and you keep the part you'd otherwise rebuild from nothing.

None of this requires giving up the managed model:

• A pinned model version recorded in the agent object, so a result is reproducible later.
• Agent specs written to my repository by default. Give me a control plane that syncs to git instead of replacing it.
• A documented export path, even a lossy one, from a declarative agent to a framework agent.
• Cost attribution per agent invocation, surfaced while I build rather than after I ask.

That last one already half exists. CoCo could query its own usage tables and explain its own bill. I just had to know to ask, and most people won't.

I still go cloud-agnostic for my own work, and for me that means PydanticAI. But I'd stop short of telling a two-person data team with compliance obligations that they're doing it wrong. They're not. They're buying the part that's hardest to build, and paying for it in portability they may never need to spend.

Know where the walls are. Then decide whether you mind.