Your Agent Doesn't Just Deploy the Backend. It Can Run It.
Most agent-infrastructure stories stop at "the agent deployed it." A real run this week went further: an agent uploaded, packaged, and delivered a review copy, then reported an operational mistake nobody asked it to check. Here is why that only works when the agent is calling real, unmodified open-source APIs.
Most stories about AI agents and infrastructure stop at the same place: the agent deployed something. A database exists now, or a hosting slot, or a bucket. That is real progress over a person clicking through a console by hand, but it is also only half the job. Deploying a thing and operating it are different skills, and most platforms only ever hand an agent the first one. This week an agent working against Eyevinn's own open-videocore instance did both, on a real task. Someone needed a 656 MB video file ready for an editor named Magnus to review, by a deadline. The agent uploaded it, packaged it for streaming, and handed back a playback link, five HLS renditions, no one touching a console. Then it did something nobody had asked it to do: it reported that making the output bucket public had exposed more than the one file, every other packaged asset on that instance was reachable too. We wrote up the full run on Eyevinn Technology's Medium publication, and the endpoint-by-endpoint call sequence behind it on dev.to (both linked below). That second part is the one worth sitting with.
The step most 'agentic infrastructure' stories skip
An agent that can call a deploy tool is not news any more. Plenty of platforms expose one now. The open question that actually matters is what happens next: can the same agent operate the thing it stood up, and can you trust what it tells you about that afterward. open-videocore answers the first half by design, it is a plain REST API with a committed openapi.json, so an agent already connected to it can create an asset, poll its status, execute a transcode-and-package job, and fetch the delivery link, the same calls a person or a script could make. The second half, the trust question, showed up unprompted in the run above: the agent flagged its own operational mistake because it could see the actual state of the bucket it had touched, not a summary of it.
How an agent operates a service without ever holding a credential
The mechanism generalizes past this one example. Connect an AI coding agent to the OSC MCP server once (claude mcp add --transport http osc https://mcp.osaas.io/mcp, then authorise over OAuth 2.1 with PKCE) and from then on it can look up any My App or service instance you have running and call it, OSC's MCP layer authenticates the request on the agent's behalf. There is no instance URL to paste into a prompt and no bearer token sitting in a chat transcript that could leak if that conversation is ever logged or shared. For open-videocore specifically, that means the agent driving the upload-transcode-package-deliver sequence never held a credential to lose. The same pattern is what already lets an agent provision a database or object store through the same MCP connection; operating a running service is the same trust boundary applied one step further downstream.
Why this is the part that should change how you evaluate a platform
Here is the buyer question underneath all of this. An agent that reports honestly on what it did can only do that if there is nothing standing between it and the real system, no proprietary wrapper smoothing over what actually happened. The agent in this run could tell us about the public bucket because it was talking to open-videocore's own real API, the same one you could call directly, not a simulated or abstracted version of it. That is a different, more concrete claim than the usual portability pitch. Zero lock-in is normally sold as "you can export your data and leave." The version that matters day to day is smaller and checkable right now: you can see exactly what your agent did and why, because every call it made is a call you could make yourself, against unmodified open source, not a black box with a chat window on top.
Frequently Asked Questions
What is the difference between an agent that deploys infrastructure and one that operates it?
Deploying means the agent provisioned a service, a database, a bucket, a running instance. Operating means the agent can also call that service's real API afterward to do the actual work, upload a file, run a job, check a status, and report back honestly on what happened, including mistakes. Most agent-infrastructure demos show the first. This post is about the second.
Does this only work with open-videocore, or with any OSC service?
The specific example in this post is open-videocore, which publishes a plain REST API with a committed openapi.json. The underlying mechanism, an agent connected over the OSC MCP server looking up a running instance and having OSC's MCP layer authenticate the call, is the general pattern behind every service instance and My App on the platform, not something built one-off for this example.
Do I need to hand my agent a token or an instance URL to make this work?
No. Once your agent is connected to the OSC MCP server (one line to add it, then authorise once over OAuth 2.1 with PKCE), it looks up your service instances itself and OSC's MCP layer authenticates each call. There is no bearer token for the agent to hold, paste, or accidentally leak in a shared conversation.
Related Posts
Give your AI agent a backend it can deploy, and you can walk away with
Your AI coding agent can build the app. OSC gives it a backend to deploy through one MCP connection, built from unmodified open-source services you can export and run yourself, on any cloud, any time.
Add an MCP Server to Your Stack in One Line
Connect your AI coding agent to real infrastructure. Add the Open Source Cloud MCP server in one line and let your agent provision and run open-source services.
Vibe Coding Meets Open Source Deployment
AI writes the code. But where does it run? Vibe coding tools generate applications in minutes — yet deployment remains the gap. Open Source Cloud bridges that gap with zero lock-in infrastructure that AI agents can provision directly.