
@paddixi
iAccount based inUnited States
About this account
- Account based in
- United States
- Connected via
- United States App Store
Account-level information from X, not a live location or the device used for a specific post.
CEO at DigitalOcean
Boston
Joined October 2007
- Tweets2.2K
- Following1.9K
- Followers5.2K
- Likes273
If you have feedback on our console experience, please DM @ld_do_ from our product team. Genuinely interested in making the experience better and we will send some cool swag your way !!
Beam from @reflection_ai is now on @digitalocean.
501B parameters, 23B active per token. Reflection reports comparable reasoning quality with ~3x fewer reasoning tokens.
For production agents, efficiency matters on every turn.
.@reflection_ai reports Beam matches leading open models on quality with about 3x fewer reasoning tokens. It's a 501B sparse MoE with only 23B active per token, and Reflection's first open-weight model.
Now on DigitalOcean Serverless Inference and Dedicated Inference. $0.40 input, $1.20 output per 1M tokens. do.co/4xsz0fI
Paddy Srinivasan retweeted
Some things never change; latencies matter in agentic scenarios (else you run the risk of having the agent drop you in a free market). With 20,000+ tools and counting, Action Gateway continues to perform world class in selection of tool and latencies for tool calling scenarios. Blog coming next week, but like you know already I like to share our sneak peeks 👀
If you'd like to learn more, check out Managed Agents: digitalocean.com/blog/manage…
An agent’s unit of work is an entire execution loop:
Model call → tool invocation → code execution → state update → a different model call → evaluation.
One user request can repeat that loop dozens of times. Inference latency, context reuse, runtime startup, credential handling and state persistence all affect the cost and reliability of completing the task.
That changes what the cloud needs to optimize.
A fast model endpoint helps. So does a fast sandbox. But every handoff between services can introduce another network hop, authentication boundary, failure mode or gap in the trace. Those costs compound across the loop.
At @DigitalOcean, we’re building these primitives to work together:
• Inference routing with visibility into the serving layer and opportunities for KV-cache reuse.
• Isolated microVMs that pause while an agent waits and resume when execution is needed, with active CPU billing.
• Governed tool access through MCP, with credentials brokered at invocation so secrets stay outside the agent’s context.
• Persistent agent data, execution traces and evaluations that help teams identify failures and test improvements.
The optimization target is cost, latency and reliability per successfully completed task.
And there’s a longer-term opportunity: using the history of those tasks to improve the application’s prompts, tools, memory and workflows.
Bring your model and harness. Build intelligence that becomes more valuable with use.
@jenukal goes deeper on the architecture 👇
A hypothesis: agents don't need a sandbox. They need a platform that thinks, acts, remembers, and improves as one system.
There's a debate running this week about sandboxes. One camp says sandboxes are dead and the future is a private cloud for every agent. Another says a sandbox is a compute primitive, like Postgres or Redis, and primitives don't win markets, platforms do. A third says sandboxes are a winner-takes-most market. I think all three are arguing about one layer of the problem.
My hypothesis is that agents are the first workload that exercises every layer of a platform inside a single loop. They think, they act on real systems, they remember, and they improve.
A web server touched compute and maybe a database. An agent touches inference, execution, tools, storage, retrieval, telemetry, and evaluation, in one task, often in less than a minute. So what an agent needs isn't a better sandbox. It's a platform where those four things run as one system. If that's right, the unit of competition isn't the sandbox and it isn't the model. It's the integrated cloud for agents.
Whoever builds one that's compelling across agents, data, and model access at the same time wins.
Let’s start with how an agent actually runs. One “prompt” fans out into a dozen model calls, a web search, a database query, a code execution, a tool call with a credential, a checkpoint, and a trace. Today a typical team buys those from five or six vendors and glues them together. Six vendors means fifteen seams. Every seam is an integration someone maintains, a credential someone stores, a network hop that adds latency, an egress fee, and a place where the trace dies.
Point solutions are excellent but partial: most sandbox companies don't run inference, and model companies don't manage agent memory or observability. The loop is what breaks on a stitched stack.
Models have to be routable, and routing only works when inference sits next to the agent. Every few weeks a new model tops a chart. Open-weight models went from <20% of token volume on our Inference Engine in April to >85% by August.
My read: the model is the most swappable layer in the stack, so you want a router in front of it, not a hard-coded choice. We built an Inference Router for that. On Kimi K3 we see an aggregate cache-hit rate above 90% across our own workloads. The router has to know what the inference layer has cached, and the cache has to sit next to the sandbox that's going to need it. That's a function call on one platform.
The agent and harness layer is where the business logic lives, so the runtime has to be built for it. I believe the harness, its prompts, its tool permissions, its memory, and its evals will hold more of a company's business logic than the model ever will. The model is rented. The agent is yours. So we built Managed Agents from the ground up as purpose-built primitives, not VMs with an agent sticker on them. Every session gets its own Firecracker microVM, resumes from pause in a few hundred milliseconds, and is billed for active CPU at $0.044 per vCPU-hour, so the wait costs zero. Action Gateway gives agents governed access to 20K+ tools across 600+ providers through one MCP endpoint, matched intent to tool with 99%+ accuracy in our testing, and brokers credentials at call time. The agent never sees the key. You can only make that promise when the runtime, the gateway, and the secret store are the same system.
Data and recursive loops are what make an application more intelligent over time. This is the part I believe in most and the part with the least proof so far, because the products are weeks old. The hypothesis: two teams start with the same model and the same harness, and within a quarter they diverge, and the one with the loop wins. On DigitalOcean the loop runs on two services. Agent Data Services is one governed catalog where video, documents, logs, and agent sessions land agent-ready and searchable by meaning. Agent Learning Services closes the loop: Insights records every step, Signals flags the sessions where the agent stalled, looped, or lost the user, and Evaluations and Simulations test the fix before a customer sees it. In an internal demo, an optimized support agent went from failing to passing it with 90% fewer input tokens.
Intelligence stops being something you rent via models and becomes something your application accumulates, tuned to the exact problem it's solving.
And the whole thing has to go down to the floor. DigitalOcean builds the routing model and the microVM runtime operates the GPUs they run on, across 20 data centers with NVIDIA HGX B300 and AMD MI350X fleets.
Much of the agent infrastructure market rents GPUs from someone who rents a data center from someone else, with margins stacked on margins. My view is that active CPU billing, a warm KV cache next to the sandbox, and a router that can see the inference layer are only possible when you control the data center, the hardware, and the software as one stack.
The obvious objection is that "integrated" is a polite word for lock-in. I'd argue the opposite, and I think it's the real test of whether a platform is integrated or just bundled. Integration should be about removing seams, not closing doors. Bring Claude Code, Codex CLI, OpenCode, Hermes, LangGraph, or your own OCI image. Hit one endpoint compatible with OpenAI, Anthropic, and 60+ Open models. Bring your own key for a frontier model, or run open weights we host. Our routing model and the proxy under it are open source.
The point is that the seams are gone, not that the exits are.
One early signal that the hypothesis might be right: roughly 70% of our large AI customers have attached a one or more platform primitives. Agents come in through inference or a sandbox and pull the rest of the cloud behind them. That's what I'd expect if agents really do need every layer at once.
So, back to the debate. The platform that wins won't be the one with the best sandbox, and I don't think it'll be the one with the best model.
My bet is on the platform where an agent thinks, acts, remembers, and improves as one system.
DM me if you are interested in trying our Agent primitives.
#digitalocean #agents #Agenticloop #learning #Context #sandbox #Runtime #DOCN
Paddy Srinivasan retweeted
Oh lordy 🙇 dropping some goodies on Monday. I’ll get sandbox start time < 100ms (and this is hardware isolated virtual machines, not containers) over the next three months. Owning your stack is the only way to create outsized value. To be precise: “Harness Ready” means hr_sandbox.exec is ready to run commands.
If you haven't checkout MARS (Managed Agents) from DigitalOcean id encourage you to give it a 👀. Tokens + Agentic Compute + Action Gateway (20,000+ tools) as a neatly integrated stack with unit economics that are really hard to replicate, it really is the best place to scale your agents
digitalocean.com/blog/manage…
Tune in at 1 pm PT to hear how we at @digitalocean are reimagining the Cloud in the Agentic era along with @nvidia and other partners. Live stream link below
No more manual ETL processes and waiting overnight for humans to complete the testing loop. Agents can now Recursively Self Improve in near-real time without human intervention. Today's platform releases makes it possible. Watch this compelling demo.
Your logs say "200 OK". Your customer still can’t link their bank account. That’s the failure illustrated in this demo. The agent says “try again later.” The user leaves.
Today we’re launching Agent Data Services + Agent Learning Services to help close that loop:
→ Insights traces model calls, tool calls and policy checks.
→ Signals flags tool failures and user frustration, turning production sessions into evals.
→ Data Services lets an engineering agent search across recordings, videos, docs and logs to find the root cause.
→ Simulations tests the fix on the real agent harness—including scenarios where the tool fails again.
All running on @digitalocean Managed Agents, with isolated microVMs and governed tool access. Credentials never reach the agent.
This is what a cloud built for agents needs: production experience feeding directly into diagnosis, testing and better behavior.
Watch the demo. The interesting part starts after the agent gets it wrong.
Agents needs a feedback loop around execution to recursively self-improve.
Today, we’re introducing Agent Learning & Data Services on @digitalocean's AI Native Cloud Platform
• Insights captures execution traces.
• Signals identifies failures.
• Evaluations & Simulations tests changes before rollout.
• Agent Data Services provides a governed, semantically searchable catalog for context, session history, and learning data.
Run → observe → evaluate → improve.
On one AI-native cloud.
Your agents’ experience becomes data you can use to improve their next run.
Own your intelligence !!
Fantastic use case of @Amplitude_HQ leveraging @digitalocean's Managed Agents Platform. Hear directly from @spenserskates about this next week at the Open Intelligence Summit on Tuesday the 13th
"Building an AI product goes beyond just selecting a model. It’s a systems problem.”
@vinaygo of @Amplitude_HQ on how they built Wave, a proactive agent that finds what’s worth building and hands you ready-to-merge PRs. All the time. The data science agents behind it run on DigitalOcean Managed Agents.
Hear more from @Spenserskates at Open Intelligence Summit on Tuesday. Keynote streams live: do.co/4hVe8aN
Join us on 13th to hear about this and much much more. See how the grassroots movement is shaping the Open Intelligence movement. New speakers also announced
digitalocean.com/open-intell…
“Owning your intelligence is owning your future.”
@latkins, CTO of @arcee_ai, on open weights and everything built on top of them.
Open Intelligence Summit keynote streams live Oct 13: do.co/4zo4nZS
As Agents become the basic unit of execution for any "Knowledge" task including coding, I have been thinking a lot about bottlenecks to speed up delivered-outcomes. One of my all time favorite books is "The Goal" by Eli Goldratt @GoldrattBooks. Those principles are VERY applicable for Agentic Workflows.
An agent can have a very fast model and still take a long time to get anything done.
It calls a tool, waits for the result, updates its state, makes another model call, and keeps going. The result of one step often determines what happens next.
If those steps cross clouds or regions, the network wait adds up with every turn. Connection pooling helps with TCP/TLS setup. Parallel tool calls help when the work is independent.
The dependent steps still have to wait and this is the bottleneck of the whole system.
That’s a big reason we’re building @digitalocean’s AI-Native Cloud as a full stack running in the same DC on the same fabric. Bring agent execution, inference and data close together. Use private endpoints. Keep intermediate results near the runtime. Set timeout and retry budgets that make sense across the whole task.
We ultimately care about how long it takes the agent to finish the job, how often it succeeds, and what that successful task costs. That means tracking p95/p99 completion latency, tool failures, retries and accuracy alongside inference performance.
The longer agents run, the more these details matter.
We usually move workloads. This week, we’re moving builders.
@digitalocean’s FREE #SFTechWeek shuttles run Oct 5–9, 8am–8pm. Hop on, hop off, get to your next big idea.
Find your ride on the live map:
digitaloceanevents.com/
The Open Intelligence Summit is about one simple idea: the future of AI should preserve choice.
Models will keep changing. The frontier will keep moving. Developers shouldn’t have to bet their stack on one lab, one model, or one closed ecosystem.
On Oct 13 in SF, we’re bringing together builders across models, inference, agents, tools, and open infrastructure to discuss what it takes to truly own your intelligence.
Great perspective from @rbren_dev of @OpenHandsDev.
"If you commit to one particular lab, there's a good chance you're going to be left behind."
@OpenHandsDev CEO @rbren_dev on choice and owning your intelligence. Hear more from him at the Open Intelligence Summit, Oct 13 in SF: do.co/4ArVTlL
Your TTFT benchmark is only as good as your stream instrumentation.
Reasoning models can emit reasoning_content before content. Watch only content, and you can miss tokens the model is already generating.
My takeaway: measure first streamed token and first answer token separately. Then inspect tail latency at the context lengths your agents actually use.
Those metrics answer different questions: when inference starts responding, and when your application can act.
@digitalocean’s audit 👇
digitalocean.com/community/t…
86% of agent tokens are cached prompts in this @OpenRouter snapshot.
Agents replay the same context hundreds of times per task, but the cache only hits on the same node on the same platform. Every hop is a miss at full price.
Agents and inference belong on the same platform.
Chart: @a16z Aug. 2026
Even after 30 years of futility following this stupid team, why do I still feel great after a meaningless @dallascowboys regular Week 4 season WIN that I did not even watch live ??










