Tencent EdgeOne Makers - Ship AI agents like web apps, in minutes.
Tencent EdgeOne Makers is an edge platform for modern web apps and AI agents. Build with your preferred frameworks and deploy through familiar CLI, Git, and CI/CD workflows. Get built-in agent runtime, sandboxed tools, memory, observability, model gateway support, serverless functions, and storage—without stitching together complex infrastructure. Add AI agents to existing products or launch new AI applications in minutes. Deploy AI agents like web apps.
Replies
congrats on the launch!
the idea of treating AI Agent deployment like web app deployment is really interesting.how does Makers handle long running agent workflows that may span hours or even days?
@avery_thompson2 Our platform provides two runtime modes. agents/ is purpose-built for real Agent workloads, with dedicated runtime-level design:
Session affinity: Requests within the same conversation are routed to the same instance, reusing its in-memory context, caches, and connections throughout the active session.
Extended execution time: A single execution can be configured up to 1 hour — and if that's not enough, reach out to us for an allowlist extension. This is more than enough for multi-turn agent loops, repeated tool calls, deep research, and other long-running tasks.
cloud-functions/ is a stateless, request-level autoscaling mode: each request spins up, executes, and recycles — no idle cost — ideal for data queries, helper APIs, and other short-lived logic.
Tencent EdgeOne
Just to add a bit — for longer workflows, a big focus for us has been making sure things don’t feel broken up between steps.
Tencent EdgeOne
@avery_thompson2 Great question.
We don't keep one process running for hours or days — a single run is time-bounded by design. Long workflows are durable instead: state lives in the conversation store (keyed by conversation_id), so a later run resumes right where it left off, and cron (schedules in edgeone.json) can wake the agent to continue or kick off the next step. So "spanning days" = persist + resume across runs, not one never-ending execution.
Edge deployment for agents = low latency for users worldwide without me thinking about regions. That's a strong angle.
Tencent EdgeOne
@shirley_mou Exactly — you shouldn't have to think about regions at all. You deploy once, and it runs close to your users worldwide on the edge. Glad that angle landed for you — it's one of the things we care about most. 🙌
Tencent EdgeOne
@shirley_mou Glad that resonated with you! As builders ourselves, we really wanted the deployment experience to feel effortless—so you can focus on the fun part: building the agent. 😄
Congrats @kitty_lee1 and team. The sandboxed tools part is the most interesting to me. Do you have examples of what kind of tool permissions or isolation developers can control?
Tencent EdgeOne
@kitty_lee1 @thea5
Thanks! The sandbox is the part we're most proud of too. Each agent runs in an isolated environment, and you get control over things like which tools it can call (web search, code execution, browser, shell, file access) plus guardrails like execution timeouts and interrupt control — so a misbehaving or long-running task can't run away with your resources. Happy to go deeper on the permission model if it's useful — what's your use case?
@kitty_lee1 @tobias_lau That makes sense, thanks! My use case would be agents that can help with small product/dev workflows — things like reading project files, running code, checking docs, maybe opening a browser — but I’d want pretty tight control over what each agent can access.
Curious if permissions are usually configured per agent, per workspace, or per task?
@kitty_lee1 @tobias_lau @thea5 That's a great use case!
Permissions are configured at the Agent level in code. Each Agent decides which tools to expose to the LLM, and each Agent has its own independent handler, where you explicitly choose which capabilities to register.
In addition to tool-level permissions, every session runs in its own physically isolated sandbox environment. The filesystem, browser session, and shell of Agent A are completely isolated from those of Agent B.
Tencent EdgeOne
@thea5 Thanks! The sandbox is honestly the part I personally pushed hardest on. When we started, our view was simple: if you're going to let an agent execute code, browse, or touch files on behalf of real users, isolation can't be an afterthought — it has to be the default.
So today each agent runs in its own isolated environment, and you control exactly which tools it can reach — code execution, browser, shell, file access — with timeouts and interrupt controls so nothing runs away with your resources. Happy to walk you through the permission model in more depth — what are you looking to build?
@kitty_lee1 Love that framing, isolation as the default feels really important once agents can touch real user files or execute code.
I’m thinking about agents for weekend product builds, where I’d want to let them use code execution/browser/file access, but only inside a bounded project context. Would be super interested to see how granular that permission model gets.
@kitty_lee1 @thea5 We're glad this matches your requirements!
The scenario you described—"being able to execute code, access a browser, and work with files, while remaining constrained to the project context"—is actually the default behavior of our sandbox and requires no additional configuration.
More specifically, the permission model can be controlled at this level of granularity:
1. Physical isolation is the default, not an option
Every session is automatically assigned its own isolated machine. The Agent can execute code, read and write files, and run browser sessions within that environment, but it is inherently confined to its sandbox and has no visibility into the data of other users or sessions.
2. Tool permissions can be controlled at the operation level
You decide in code which tools the LLM is allowed to use, and you can be even more restrictive if needed—for example, granting read-only access while disabling write and delete operations.
It's interesting how much of user experience depends on things people never see directly. Faster load times and reliability rarely make headlines, but users definitely notice when they're missing. Nice work.
Tencent EdgeOne
@harini_mukesh Well said — the invisible stuff is the whole job. Speed and reliability only get noticed when they're gone, so we'd rather you never have to think about them. Thanks for the kind words!
Tencent EdgeOne
Well said. The things users rarely notice are often the things teams spend the most time getting right.
Tencent EdgeOne
@harini_mukesh Well put — the best infra is the kind nobody notices. Nobody opens an app thinking "wow, great cold start," but they definitely leave when it's slow. We spend most of our time on exactly that invisible layer, so developers (and their users) never have to think about it. Thanks for seeing the part that usually goes unseen!
The fact that I can start from a working example instead of a blank repo is underrated for actually shipping.
Tencent EdgeOne
@cynthia220 This is so underrated — a blank repo is where a lot of good intentions quietly die. We see it in the data too: starting from a working example dramatically changes whether people actually get to a deployed agent vs. stalling on setup. That's exactly why we lead with templates. Thanks for calling it out!
Tencent EdgeOne
Yeah. That first working version really changes everything.
congratulations on the launch! supporting both Python and JavaScript is a huge plus.are there plans to expand support for additional languages in the future?
@imogen_wallace Thanks! We chose Python and JavaScript first because they cover the vast majority of agent development today — most LLM SDKs (OpenAI, Anthropic, LangChain, CrewAI) are Python-first or JS-first, so supporting both means developers can use their preferred framework without compromise.
If there's a specific language or runtime you're thinking about, we'd love to hear it — it helps us prioritize.
Tencent EdgeOne
Thanks! One thing we cared about a lot was meeting developers where they already are, instead of asking them to switch languages or workflows just to deploy an agent.
Tencent EdgeOne
@imogen_wallace Thanks! Python and JS cover most of what people building agents reach for today, so those were the natural starting point. More languages — yeah, definitely something we're thinking about, but we'd rather let real demand drive that than just add stuff nobody asked for. What language are you hoping for?
congratulations to the team! i appreciate the focus on reducing infrastructure complexity.how does pricing scale for teams that suddenly experience rapid user growth?
@olivia_bennett7 EdgeOne Makers currently offers a free plan. Before the official commercial launch, usage limits for the free plan are enforced with some flexibility. Even if you exceed your quota, we will prioritize the stability of your services. If you need a higher quota, please contact us to request a quota increase.
Tencent EdgeOne
@olivia_bennett7 Thanks for the support! Honestly, we are currently in our free beta phase, so you can experience full capabilities with zero infrastructure costs right now.
As we look toward future commercialization, our goal remains to keep infrastructure accessible and affordable for growing teams. We’ll definitely design generous quotas for scaling startups.❤️
BiRead
Finally, agent hosting that doesn't make me wire up five services first. Nice work!
Tencent EdgeOne
@luke_pioneero "Five services" hit a little too close to home 😅 That's exactly the pain we wanted to kill — memory, sandbox, tools, tracing all come wired in, so you can just ship the agent. Thanks, glad it resonates! 🙌
BiRead
@tobias_lau Haha exactly 😄 The moment I saw memory, sandbox, tools, and tracing bundled together, I knew what pain you were going after. Excited to try it on a real agent project.
Tencent EdgeOne
Haha yeah. Getting all the infra pieces out of the way is kind of the whole point for us.
BiRead
@kassy_kane That’s the part I appreciate most. Agent ideas are easy to prototype, but the infra checklist gets long fast. If Makers can make that disappear into the background, that’s a big unlock.
Tencent EdgeOne
@luke_pioneero That line is basically why we built it — memory, tools, tracing, storage all come with the runtime, so you ship the agent, not the plumbing. Thanks! :)
ReplyMind
Congrats on the launch 🚀 Tencent EdgeOne Makers looks like a platform I’d genuinely want to try — deploying AI agents with built-in runtime, sandboxed tools, and edge performance feels like it could save me tons of setup time.
Tencent EdgeOne
@moon10 Thanks! You've pretty much summed up why we built it — runtime, sandbox, and edge handled for you so the setup time goes back into building. If you do try it, I'd genuinely value your read on the first-deploy experience; that's the part we care most about getting right.
ReplyMind
@tobias_lau That's amazing!
Tencent EdgeOne
That “less setup, more building” feeling is exactly what we were going for. Would love to hear how it feels if you try it out .
Nice launch! The deployment experience looks really clean.
One question: how do you handle long-running agent workflows? For example, if an agent needs to wait for user approval or perform multiple asynchronous steps, is there built-in state management or checkpoint support?
Tencent EdgeOne
@qiwap Thanks! State management is built in — the conversation store (keyed by conversation_id) persists across runs, so a workflow that pauses for approval just resumes when the next request lands on the same conversation. Since a single run is time-bounded, the model is persist + resume (cron can drive scheduled steps too), not holding a process open.
On checkpoints specifically: there's no automatic durable-execution engine baked in — but if your framework has a checkpointer (e.g. LangGraph), you point it at the store. So: state, yes; automatic step-replay is on your framework.
Tencent EdgeOne
Yeah good question. Once you move into multi-step / async workflows, having a way to persist state and resume becomes pretty important.