Tencent EdgeOne Makers - Ship AI agents like web apps, in minutes.

@kitty_lee1 Congrats on the launch. Quick question; for Agents that need to interact with external APIs and user data, what best practices or built-in safeguards does Tencent EdgeOne Makers provide to prevent data leakage and ensure least-privilege access across sandboxed tools, third-party integrations, and persisted memory?

@kitty_lee1 Congrats on the launch!

@kitty_lee1  @rocsheh Thanks for your support!

We support direct deployment from GitHub repositories, similar to how Vercel works.

As for the sandbox, the current limits are:

• A total monthly memory-time quota of 100,000 GB-seconds.

• A maximum runtime of 1 hour per instance.

These settings can be configured on a per-Agent basis. If you require higher quotas, feel free to contact us to request allowlist access for increased limits.

For a complete list of limits and quotas, please refer to:
https://pages.edgeone.ai/document/limits-and-quotas

Really appreciate the thoughtful feedback. The GitHub template idea is a good one — anything that gets people from "I have an idea" to "it's live" faster is worth paying attention to.

And if you do spin something up, we'd genuinely love to hear how it goes!

  @rocsheh The "third option = personal attack" line genuinely made my day 😂 — hand-stitching LangGraph + memory + sandboxed tools is the exact pain we couldn't unsee, so it means a lot that it resonates.

Really appreciate the GitHub one-click template idea too — "fork to live in 30 seconds" is exactly the kind of moment we obsess over on the growth side, so this is great signal for us. And on your timeout/resource-limit question, looks like the team already jumped in with the details below 🙏

Enjoy spinning it up tonight — would love to hear how the first deploy feels. That early feedback is gold for us. 🔥

@abod_rehman Thanks! The key design choice here is that sandboxed tool execution lives at the runtime layer, not inside any specific framework — so it behaves consistently whether you're on Claude SDK, LangGraph, or CrewAI. The framework handles your agent logic; the sandbox, isolation and tool execution sit underneath and work the same for all of them. That said, we do ship starter templates for each so you get a smooth zero-config start.

@abod_rehman 

Where framework-awareness kicks in is at the tool interface layer (context.tools) and memory layer (context.store). Both adapt automatically based on a framework field in edgeone.json — so Claude SDK, LangGraph, and CrewAI each get their tools and conversation history pre-wrapped in the format they natively expect, without any glue code on your side.

@abod_rehman Same execution across all of them — one sandbox, same atomic tools. The only per-framework difference is the binding format, and Claude SDK / LangGraph / CrewAI are all first-class (OpenAI Agents SDK too). You set framework in edgeone.json and context.tools hands you objects already shaped for it — no glue code.

@blah_mad In our platform, an agent is treated as a project. Access control for agent invocations can be managed through our middleware layer. Regarding tools, each agent explicitly registers the subset of tools it is permitted to use within the framework.

@artstavenka1 Great question — and you're right that edge V8 is tuned for short requests. So we don't run agents on the edge.

Agents run on a dedicated cloud runtime built for long, stateful work: a single run goes up to1 hour, also with a sandbox (for tools/code) up to 1 hour.

• Runs for minutes → sticky-routed by conversation_id, so in-memory state is reused, plus built-in conversation memory that persists across runs (native to Claude / OpenAI Agents / LangGraph / CrewAI). Step retries live in your framework loop.

• Picked up later → native cron (schedules in edgeone.json) can trigger an agent on a schedule, and since state is keyed by conversation_id, it resumes from the prior context.

The edge bet is really about distribution + the fast path — the heavy work runs where it should. Curious what you're building!

Love this question.The edge + long-running agent tradeoff is something we spent a lot of time thinking about when building Makers. Thanks for digging into the details.

@henry_habib We inject OpenInference-based instrumentation before your code loads, so every LLM call and tool invocation automatically becomes a structured span — with timing, inputs/outputs, token usage, and errors — without you adding any decorators or SDK imports.

Traces are viewable in both the cloud console and the local dev panel with the same UI. When a multi-step workflow breaks, just open the trace, walk the span tree to the failing step, and see exactly what went in and what came out.

Great question. In our experience, the hardest bugs are rarely in a single model call — they're usually somewhere between multiple steps, tools, and retries. That's why this area got a lot of attention from us. Appreciate you digging into it.

@henry_habib Great question — debugging failures across a multi-step workflow is exactly where most setups fall apart, so we made observability a first-class part of the platform instead of an afterthought. Happy to connect you with the team for the deeper technical details. What does your workflow look like?

@boyuan_deng1 Great question! Today it's one language per deployment — each agent runs in either a JS or Python runtime. But since Web and agents share the same project, you can absolutely have, say, a Python agent and a JS service running side by side and talking to each other. Mixing both within a single agent isn't supported yet — curious, what's the use case you had in mind? It'd help us think about where to take this.

Curious what scenario would require mixing both 🤔 would love to hear more.

@boyuan_deng1 One language per agent — a single agent runs as one runtime (JS or Python), not both in the same process. But the project is polyglot: you can run JS and Python agents/functions side by side in one deployment, routed by file and sharing the same domain + env. Need both? Split them into separate routes and call between them.

@jocky Exactly the thinking behind it. Most stacks force you to treat your web app and your agent as two separate worlds — different repos, different deploys, glue code in between. We figured if they share the same project, account, and deploy flow, that whole layer of friction just disappears. Glad it resonates — thanks!

Really glad that resonates Keeping everything in one flow just felt like the most natural way to build it. Appreciate the feedback!

@orman_canida Thanks — the sandbox is my favorite part too.

Isolation: every conversation gets its own sandbox instance (Tencent Cloud isolated instances), keyed by conversation_id and physically isolated from other conversations. It auto-recycles on timeout, and you can extendTimeout() or kill() it yourself.

Tool permissions: you decide exactly which tools the LLM can see — context.tools.all() for everything, grouped subsets like context.tools.files() / context.tools.browser(), or hand-pick with context.tools.get(name). So you can hand an agent only file access, without shell or browser.

On the developer side you also get the raw atomic APIs (context.sandbox.commands / files / browser / runCode), with per-command control over user / env / cwd / timeout.

Happy to point you at a template if you tell me what you're building!

Great question. One thing we've learned is that once agents start interacting with real systems, permissions and isolation become just as important as model quality. Really appreciate you digging into this part.

@carlvert You just described our entire reason for building this. The "boring stuff" is exactly where projects stall — and it's boring precisely because everyone has to rebuild it from scratch every time. We figured that should just come with the platform, so you can spend your time on the agent, not the plumbing. Thanks for getting it so precisely!

Yeah, that’s exactly the gap we kept seeing too. Glad this resonates — really appreciate you putting it so clearly.

@carlvert Couldn't agree more — the demo-to-production gap is all that "boring" plumbing. That's exactly why Makers bakes it in: memory, tracing, scaling, and storage come with the runtime, so you're not wiring four services together before you can ship. Keeps the fun part fun.