From Deployment to AI Features: Exploring Tencent EdgeOne Makers with Acadexa and XPense

I first used Tencent EdgeOne for one thing: deploying websites.

I wanted to get my projects online and keep improving them. At that stage, hosting was a practical part of the work: build an interface, make it accessible, and return to the next feature.

The newer Makers capabilities have given me a reason to look beyond deployment. The console now puts Agents, Models, and Storage alongside the project settings. Looking at those features, I started thinking about two projects I have already built: Acadexa, an academic progress tracker, and XPense, a personal expense-tracking interface.

Both already have useful data and application logic. The next questions are about what happens around them: how an assistant could explain a student's workload, how a conversation could retain context, or how a generated report could remain available after someone closes the browser.

My experience with EdgeOne so far is deployment. The agent, model, and storage integrations in this article are planned extensions, illustrated with examples based on the current documentation. I have not implemented or benchmarked them in either project yet.

Two projects, two starting points

Acadexa and XPense are separate applications. I am using both here because they expose different versions of a similar engineering problem: an interface can display useful information long before the application has a persistent, contextual assistant behind it.

Project	Current implementation	A useful next capability
Acadexa	HTML, CSS, and JavaScript; a planner, dashboard, academic analytics, profile, and rule-based insights	Explain unfinished tasks in the context of a student's available study time
XPense, in project_ui	Next.js, React, and TypeScript; expense tracking, budgets, analytics, gamification, and a rule-based chat interface	Explain spending patterns using the user's recorded transactions and budgets

Acadexa: the tasks are already there

In Acadexa, a task contains a title, course, priority, deadline, and status. The planner stores the collection in the browser:

let tasks = JSON.parse(localStorage.getItem("acadexaTasks")) || [];

function saveTasks() {
    localStorage.setItem("acadexaTasks", JSON.stringify(tasks));
}

That is the current implementation in js/planner.js. The insights module then calculates completion percentages and generates recommendations through JavaScript conditions.

This gives an AI feature a concrete starting point. The application can supply unfinished tasks and calculate progress itself. An assistant could help a student interpret the list, discuss trade-offs, and turn a vague intention into a manageable next step.

For example: “I have 45 minutes tonight. Where should I start?”

The current task records do not include estimated effort. A responsible answer would need to ask about that or make its assumptions explicit. A confident sentence cannot fill in missing data.

XPense: the numbers should stay in code

XPense has a similar foundation. Its local store maintains transactions, budgets, and progress information. Category totals are calculated directly:

export function getSpentByCategory(transactions: Transaction[]): Record<string, number> {
  return transactions.reduce((acc, tx) => {
    acc[tx.category] = (acc[tx.category] ?? 0) + tx.amount;
    return acc;
  }, {} as Record<string, number>);
}

The current AI Buddy interface uses keyword matching and prepared response logic. A model-backed version could support more flexible questions while continuing to use these calculated totals.

That separation matters to me. If someone asks why food spending increased, code should determine the amounts and comparison period. The model could explain the result in ordinary language, ask a follow-up question, or point out that the available history is too limited for a useful comparison.

What Makers changes about the next development step

Tencent's documentation describes EdgeOne Makers as the evolution of EdgeOne Pages, adding native agent capabilities to its web development and deployment platform. The platform brings together frontend delivery, functions, an agent runtime, model access, and storage. The product introduction describes the upgrade.

For my projects, this creates an integration path on a platform I already use for deployment. I can evaluate a managed runtime and model gateway before deciding which infrastructure I need to operate separately.

There is still backend work to do. User identity, ownership of records, validation, and update correctness belong to the application. Managed infrastructure changes how I can run that work.

I would place the main responsibilities like this:

Layer	Responsibility in a future version
Frontend delivery	Serve the interface and its assets through the edge network
Edge Functions	Handle lightweight requests and supported KV lookups near users
Cloud Functions	Run backend operations requiring Node.js dependencies or database access
Makers Agents	Coordinate conversations, model calls, tools, and agent state

These runtimes have different capabilities. Edge Functions use a Web API-oriented environment, while Cloud Functions provide runtimes such as Node.js. The Node.js SDK examples below belong in a compatible server-side runtime.

A nearby gateway is one part of the request

Imagine a request that only needs a small cached value. Serving it through a nearby function can avoid a trip to a separately maintained regional application server.

An AI request may still need several other trips: fetch the user's records, call a model provider, execute a tool, and save the result. The inference service and authoritative database have their own locations and response times.

That is how I would evaluate the architecture: measure time to the first token, time to the completed answer, and the operations responsible for slow requests. Edge delivery provides a place to reduce overhead. Its effect on the complete AI workflow needs measurement.

Makers Agents: keeping a conversation connected to the application

For Acadexa, the first agent I would build is a study-planning assistant with read-only access to the student's tasks.

The useful part is continuity. A student could ask which task to start, explain that one assignment needs a longer session, and then request an updated plan. Each turn should build on the same conversation and the current task records.

Makers Agents provides a managed runtime with conversation memory, sandboxed tools, and tracing. The console includes OpenAI Agents, Claude Agent, and Deep Agents starters. I would select one framework based on the workflow and dependencies I need. The product introduction and Agents quick start cover those capabilities and entry points.

For an OpenAI Agents SDK integration, the documented framework declaration in edgeone.json is:

{
  "agents": {
    "framework": "openai-agents-sdk"
  }
}

The initial application flow would be small:

1. Authenticate the user and verify access to the conversation.
2. Retrieve the relevant tasks or transactions.
3. Combine those records with the conversation context.
4. Return an explanation or proposed plan.

For XPense, the same structure could support follow-up questions about a spending summary. A user might first ask about a category, then clarify which dates they intended. Conversation context would help preserve that discussion; the underlying totals would still come from the application.

Makers associates agent requests with a conversation through the Makers-Conversation-Id header. Keeping that ID stable supports continuity. The application also needs an authorization check tying the conversation to the authenticated user. The quick start documents the header contract.

Persistence has another detail: the framework adapters exposed through context.store can preserve conversation history, while resuming an interrupted agent run may additionally require saved execution state. That becomes relevant when a future tool pauses for approval before changing a task or budget. The conversation storage guide explains the distinction.

Sandbox tools would become useful for a later feature, such as processing an uploaded file. I would scope their access to that operation and keep user-submitted content separate from trusted application instructions.

Tracing would help explain failures along this path. A slow response could come from record retrieval, a repeated tool call, or the model provider. I want those operations to be visible individually, with credentials and unnecessary personal data kept out of logs.

Makers Models: a common interface for model calls

Once the application has the right context, it needs a way to send it to a model.

Makers Models provides a unified gateway for supported providers. The application uses a gateway key, while provider keys can be hosted through the platform. This reduces the provider-specific authentication logic that would otherwise spread through the backend. The Models overview describes the gateway.

Here is the minimal server-side integration pattern:

import { createAiGateway } from "@edgeone/makers-models-provider";
import { generateText } from "ai";

const aiGateway = createAiGateway({
  apiKey: process.env.MAKERS_MODELS_KEY,
});

const { text } = await generateText({
  model: aiGateway("@makers/deepseek-v4-flash"),
  prompt: "Analisis data pengguna untuk Acadexa",
});

The model ID includes the @makers/ prefix. This example follows the currently documented built-in model ID; availability should be checked against the console when implementing it. The integration guide contains the SDK example and model-selection rules.

The Indonesian prompt means “Analyze user data for Acadexa.” It demonstrates the call structure, but supplies no actual task data. A real endpoint would retrieve authorized records, select the necessary fields, and construct the model input from those facts.

For Acadexa, that could mean unfinished tasks plus the student's stated time budget. For XPense, it could mean category totals, the selected period, and the associated budget. Neither requires sending the entire user profile or every historical record by default.

The gateway key stays on the server. Browser code calls the application endpoint, where identity, request size, and usage limits can be checked before making a model call.

The generateText example waits for the completed output. Makers also documents SSE support, which would allow a conversational interface to display an answer progressively when implemented with a streaming API. The model still needs time to generate the response. See the Models overview for streaming support.

A shared interface also makes model experiments easier to organize. Each candidate still needs evaluation on the same application questions: does it use the supplied facts, admit missing information, and produce a useful answer?

Makers Storage: deciding what should survive the browser

Both projects currently keep important state in localStorage. That is useful for trying an interface and its interactions. Persistent accounts and cross-device access require another step.

The storage choice depends on the data:

Data	Storage approach I would evaluate
Academic reports, expense exports, and uploaded documents	Blob storage for file objects
Small cached preferences or non-authoritative session metadata	KV for values that can tolerate brief staleness
User accounts, tasks, budgets, and transactions	An authoritative database with ownership checks and suitable update guarantees

Conversation history has its own integration through the agent runtime. I would avoid making one collection serve simultaneously as a chat transcript, account database, and file store.

Blob for reports and documents

Acadexa already creates an academic PDF in the browser using jsPDF. That behavior is visible in its analytics module. A useful extension would let a student retrieve an earlier report from another device. XPense could use the same storage capability for a future export feature.

Makers Blob persists objects in cloud storage and accelerates reads through edge nodes. Its Node.js SDK is @edgeone/pages-blob, and the project namespace is created on first use. The Blob documentation explains the storage model.

This adapted example writes and reads a small metadata object in a Node.js Makers Function:

import { getStore } from "@edgeone/pages-blob";

export async function onRequest() {
  const store = getStore("acadexa-storage");
  const key = "examples/report-metadata.json";

  await store.set(
    key,
    JSON.stringify({ project: "Acadexa", status: "ready" }),
  );

  const data = await store.get(key, {
    type: "text",
    consistency: "strong",
  });

  return new Response(data, {
    headers: { "Content-Type": "application/json" },
  });
}

I used a strong read because the example immediately retrieves the object it has just written. Blob reads are eventually consistent by default; strong reads bypass the cache to retrieve the latest value and can take longer. The Blob API documents both options.

This demonstrates the SDK operation. A real report endpoint would use authenticated access, user-scoped keys, and separate creation and retrieval paths. Its stored metadata would point to the actual report object.

For reports, I would prefer a unique key for each generated version. A reader could then retrieve a specific document without competing with another request overwriting the same filename.

KV for context that can tolerate staleness

Makers KV is currently available within Edge Functions. Its documentation describes eventual consistency, with other edge nodes potentially retaining an older value for up to 60 seconds after an update or deletion. The KV guide details that behavior.

That makes the consistency requirement part of the feature design. A cached display preference can often tolerate a delay. A revoked login or changed access permission may require an immediate authoritative check elsewhere.

Concurrent edits also need care. Moving a whole task array from browser storage into KV and overwriting it after every change would still allow two devices to overwrite each other's updates. The persistent version needs an explicit concurrency strategy for its task and transaction records.

Deployment remains the foundation

Deployment is the part of EdgeOne I already use. The newer capabilities expand the next development options around that foundation.

Makers supports Git integration and automatic builds and deployments from the configured deployment branch. I can use that workflow as the application grows, adding backend code and configuration alongside the feature that needs them. Tencent documents the Git import process here.

The two repositories also have different build needs. Acadexa contains its static files directly. XPense has a Next.js build. Keeping those project settings explicit is more useful than assuming the same deployment configuration fits both.

For future AI endpoints, I would keep secrets in server-side environment variables and review changes in a preview deployment before promoting them to production. A custom domain adds its own setup: ownership verification, DNS configuration, and HTTPS. Makers supports associating domains with production or preview environments. The domain guide covers those steps.

The release check should follow the feature. A planner change needs a working task flow. A model integration needs useful behavior when the provider is slow or unavailable. A storage integration needs the right user to retrieve the right object.

What I would build first

For Acadexa, I would start with one read-only endpoint that explains a student's unfinished tasks. It would preserve the current calculations, use authenticated records, and ask for information the task data does not contain.

For XPense, I would begin with an explanation of one spending summary. The selected dates and calculated totals would be supplied to the model. The interface would make the relevant period visible so the user could check what the answer refers to.

Those are small enough features to evaluate before adding persistent conversations, file tools, or more elaborate workflows.

I would also track operating cost from the beginning. Built-in Makers models have limited quotas, while provider-backed models can charge the connected provider account. A useful estimate needs the number of model calls, token usage, and retries, alongside function and storage usage. The integration guide distinguishes the model funding options.

For a developer working on individual projects, a managed runtime can reduce the infrastructure that needs hands-on maintenance. It leaves room to focus on questions the platform cannot answer for me: what the feature should do, which records it may use, and how someone will know whether its answer is useful.

That is what interests me about the move from deployment to these newer Makers capabilities. I already have two applications with interfaces, data, and rules. The next experiment has a clear place to begin.

A student opening Acadexa should be able to understand which task deserves attention. Someone opening XPense should be able to trace an explanation back to their recorded spending. Those are the results I want to build toward, one feature at a time.