Overview
Makers Agents is an out-of-the-box Agent development and deployment platform. Developers write Agent logic in the
agents/ directory, and the platform provides session-level runtime, sandbox tools, session management, end-to-end tracing, and built-in models, allowing you to focus on business rather than building underlying infrastructure.Platform Advantages
Out of the box: The runtime environment, sandbox, session management, and observability capabilities are managed by the platform, eliminating the need to set up basic services separately.
Designed for Agents: Routes by session and reuses context, cache, and connections while an instance is alive. It supports multiple rounds of tool calls and long-running task orchestration.
Flexible and open: Choose any framework (Claude / OpenAI / LangGraph / CrewAI) and any language (JS / Python). Use native framework syntax without introducing platform SDKs.
All-in-one delivery: Agent, access layer, and Web frontend coexist in the same project, eliminating the need to build separate services for business APIs. Accounts, monitoring, and domains are managed centrally.
Core Capabilities
Capability | Description |
Session-level Runtime | Supports Agent loops, tool calls, and long-task orchestration, and routes sessions by conversation_id for session affinity. |
Sandbox Tool | Provides two independent but interoperable API layers for both LLM and developer perspectives, with browser, code execution, Shell, and file operations all running in an isolated sandbox environment. |
Conversation Management | Provides framework-native storage adapters and general-purpose APIs, and saves conversation message history across instances. |
Observability | Automatically collects call traces, performs zero-intrusion instrumentation, and provides a unified view of trace data on local / cloud panels. |
Built-in Models | Automatically injects model keys, is compatible with the OpenAI protocol, and provides a limited-time free monthly model quota. |
Running Modes and Execution Units
All server-side code on the platform is deployed as functions, providing three types of execution units: Agent functions, Cloud Functions, and Edge Functions. They are divided into session-level and request-level by running mode, distinguished by the directory where the code resides, and can be used in combination within the same project.
Running Mode | Execution Unit | Code Directory | Lifecycle |
Session-level (Session Affinity) | Agent function | agents/ | Execution duration per run is configurable. Instances are kept alive per session and reclaimed after idle timeout, with a maximum session duration of 6 hours. State is retained across requests for the same conversation_id. |
Request-level (Stateless) | Edge Functions | edge-functions/ | Completes within a single request. No state is shared between requests. |
Request-level (Stateless) | Cloud Functions | cloud-functions/ | Completes within a single request. No state is shared between requests. |
Session-level: Requests are sticky-routed to the same instance by
conversation_id. While a session is active, the context, cache, connections, and sandbox mappings within the instance can be directly reused. A single execution supports long-running operation, enabling multiple rounds of Agent loops, repeated tool calls, and long-running task orchestration. Scaling is performed on a per-session basis, and instances are reclaimed after a session idle timeout.Request-level: An execution environment is independently allocated for each request and reclaimed immediately after use. No memory state is retained between requests, allowing arbitrary horizontal scaling based on request volume. Edge Functions and Cloud Functions belong to the same running mode, with differences in compute location and runtime. For runtime details of both, see Edge Functions and Cloud Functions.
How to choose
When choosing, consider whether the task requires session memory reuse, Agent tool capabilities, or a longer execution time:
Agent functions: Use when you need Agent loops, multiple rounds of tool calls, long-running task orchestration, or reuse of session memory and sandbox.
Cloud Functions or Edge Functions: No session state required. Use for authentication, business APIs, data reads and writes, webhooks, and more.
Whether an LLM is called is not a criterion. Cloud Functions can also call an LLM to perform one-off inference.
Access Layer
Agent applications typically also require authentication, session lists, and business data reads and writes. You can use Edge Functions and Cloud Functions within the same project to handle these responsibilities, allowing Agent functions to focus on in-session reasoning, tool calls, and task orchestration.
Execution Unit | Recommended Responsibility | Typical Usage |
Edge Functions | Lightweight entry logic | Identity verification, parameter check, and request routing based on business rules |
Cloud Functions | Business and data APIs | Conversation list, message history, business APIs, webhooks, and one-time LLM calls |
For example, a conversation page can read historical messages through the access layer and initiate a new round of execution through Agent functions.
context.store in Agent and context.agent.store in Cloud Functions can access the same session data.Agent
agents/ provides session affinity, long-running execution, and built-in context capabilities for Agent workflows:Session affinity: While an instance is alive, requests with the same
conversation_id are routed to the same instance, reusing the context, cache, and connections in memory.Long-running execution: The maximum runtime of a single request can be configured in
edgeone.json. The configurable upper limit increases with your plan, making it suitable for multiple rounds of tool calls, deep research, and long-running task orchestration.Context injection: Obtain request, environment variable, session management, and sandbox tool capabilities through
context. context.store also provides a general storage API and framework-native adaptation. context.tools encapsulates tools according to the Agent framework configured for the project.Three Time Dimensions
The end of a request does not mean that the session instance is immediately terminated. Similarly, an instance remaining alive does not mean that a single request can run indefinitely. You need to distinguish between the following limits:
Dimension | Description | Value | Expiration Consequence |
Single Execution | Maximum runtime per request | 5 minutes by default, Can be adjusted in edgeone.json, with the upper limit varying by plan. | The request returns 504. |
Idle Reclamation | How long after an instance has no requests is it reclaimed | 5 minutes by default, configurable | The instance and memory state are released. A new instance is created upon the next request. |
Session Lifecycle | Maximum lifetime of a session instance | 6 hours | The instance is forcibly terminated. |
The same conversation can contain multiple requests, with each request timed independently. Data that needs to persist across instances should be written to persistent storage. For details about the storage API, see Session Management.
Project Structure and Routing
The top-level directory determines the execution unit, and the file path within the directory determines the access route. The three types of functions can be placed in the same project as needed. The following uses TypeScript files as an example:
project/edge-functions/api/verify.ts → /api/verifycloud-functions/conversations/list.ts → /conversations/listagents/customer-service/index.ts → /customer-servicestop.ts → /customer-service/stop_lib/ → Internal module, no routes are generatededgeone.json → Project configuration
Rule | Description |
Directory prefixes do not enter the URL | agents/, cloud-functions/, and edge-functions/ determine the runtime mode and do not appear in the path. |
index maps to the directory root path | agents/customer-service/index.ts → /customer-service |
Other entry files map to paths with the same name | agents/customer-service/stop.ts maps to /customer-service/stop, and the URL does not include the file extension. |
_ prefix is used for internal modules | No routes are generated, and the files are provided for entry files to import and reuse. |
Three types of functions share the routing space | Paths within the same project must be unique. For example, both agents/chat.ts and cloud-functions/chat.ts map to /chat, so conflicts should be avoided. |
Built-in Models
New users receive a limited-time trial quota of 500,000 tokens, calculated at the account level and shared across all projects. The following environment variables are automatically injected when a template is used for deployment, and your business code can read them through
context.env.Variable | Description |
AI_GATEWAY_API_KEY | Gateway authentication Key, compatible with the OpenAI protocol |
AI_GATEWAY_BASE_URL | Gateway address, default https://ai-gateway.edgeone.link/v1 |
Any SDK compatible with the OpenAI protocol can be directly integrated. To switch models, you only need to change the model field without replacing the Key. For details, see Models Overview.
Core Concepts at a Glance
Concept | Description |
context | A unified context object injected by the platform on each request, carrying all sub-capabilities listed below. |
context.request | A standard Web Request object (including body / headers / signal) for reading input parameters and listening for interrupts. |
context.env | An access point for environment variables and secrets, equivalent to the secure reading of process.env / os.environ |
context.store | Session-level conversation management, automatically associated by conversation_id, supporting native message objects of five major frameworks. |
context.tools | A tool list for LLM, automatically packaged into a form that can be directly consumed by the target framework based on the framework field. |
context.sandbox | Sandbox atomic APIs ( commands / files / browser / runCode) for running commands, reading/writing files, operating browsers, and executing code in an isolated environment. |
context.tracer | An OpenTelemetry-style manual instrumentation entry point that shares the same trace link as the platform's automatic collection. |
context.agent.store | Same as context.store, exposed in Cloud Functions. |
conversation_id | A unique identifier for a session, serving as the key for routing, Store association, and Sandbox instance association. |
run_id | The unique identifier for an execution, around which traces, logs, and stop operations are organized. |
framework | A field in edgeone.json that determines the framework adaptation form of context.tools / context.store |
Scenarios
Conversational Assistant: Completes continuous tasks through multi-turn interactions such as knowledge base Q&A and shopping orders, combined with session context and tool calls.
File Processing: Parses files such as CSV, PDF, and images in the sandbox, and analyzes and organizes the results.
Scheduled Tasks: The scheduling system triggers the Agent to collect business data, perform summary analysis, and generate structured reports.
Content Generation: Produces content such as blog posts and event plans through multi-role or multi-step collaboration.
Workflow Orchestration: Handles stateful and branching tasks such as deep research, email processing, and manual approval, saving progress before continuing.
Programming Assistant: Modifies code, runs verification, and previews execution results in the cloud sandbox.
Usage Quotas
We have now launched commercial plans that provide you with higher Agents usage quotas. For differences in Agents & Sandbox quotas among plans, see Plan Comparison.