Dog Days Are the Best Time to Lose Weight: I Built and Launched an AI Health Coach from 0 to 1 on EdgeOne Makers

Disclaimer: The "Slim & Beautiful AI" introduced in this article is a personal demo project. The calorie estimates, dietary advice, and exercise suggestions mentioned are all generated by an AI model and are for daily reference only. They do not constitute any medical, nutritional, or diagnostic advice. Please lose weight scientifically and gently, and do not engage in extreme dieting.

1. The Origin: On the First Day of the Dog Days, the Scale Struck First

The Dog Days of summer started on July 15th and ended on August 23rd this year, a full forty days. There's an old saying that "losing weight during the Dog Days gets twice the results with half the effort." Regardless of whether there's any scientific basis for it, on the morning of the first day, I stepped on the scale and saw 67.5 kg—nearly 2 kg heavier than the start of the year. That number was more persuasive than any wellness article.

I had actually wanted to build my own health management tool for a long time. I'd previously made a conversational health check-in prototype with a card-based UI, but it was stuck in a "runnable" phase, far from "usable." To actually launch it for myself and friends, I'd have to piece together a bunch of things myself—which model provider to use, where to store conversation memory, how to deploy SSE streaming, how to configure domains and certificates. Just thinking about it was exhausting, so the project just sat in a folder gathering dust.

Then I happened to see that Tencent Cloud's EdgeOne was promoting a new thing called Makers, specifically for hosting Agents. I looked through the docs and felt it was exactly what I needed: the runtime is ready-made, the platform stores conversation memory for you, there are built-in free models, and you can use all of this right after deployment. It basically took over the most annoying parts of my shelved project. Alright, with forty days of Dog Days as a pretext, I'd rebuild the project from 0 to 1 and seriously push myself to lose some weight.

And so this project was born: Slim & Beautiful AI—a personal health coach Agent deployed on EdgeOne Makers.

2. What I Wanted It to Be

My requirements were simple, just three things:

1. Check in using plain language. I didn't want to click a bunch of buttons and fill out forms. Just say "Today 67.5kg, had oatmeal and boiled eggs for breakfast," and it should estimate the calories and keep the books itself.
2. It must actually remember. If I log my weight today and a few days later ask in a new chat window "How much have I lost this week?", it should still be able to answer. This requires the Agent to have long-term memory across sessions.
3. The data needs to look good. Numbers like calorie intake/expenditure and weight trends should be displayed with cards and line charts, not a wall of text.

Breaking this down, it required 7 tools: log weight (supporting historical entries), log meals, log exercise, generate a daily health report, view weight trends, set a weight-loss plan, and arrange a weekly meal plan. There's a design choice I'm quite proud of regarding the division of labor: The large model is responsible for "estimating," and the tools are responsible for "recording." When a user says what they ate, the model first estimates the portion size, calories, and protein/carb/fat levels of each food based on common sense, then passes the structured data to the tool for bookkeeping. The tool aggregates historical data from storage, calculates day-over-day comparisons, draws trends, and conveniently spits out a set of card data to the frontend. The model does the fuzzy reasoning, and the code does the precise calculations—neither oversteps its bounds.

3. Two Ways to Get Started: Point-and-Click on the Web, or All-in-One with the CLI

There are two paths to creating a project on EdgeOne Makers. I walked both, and each has its own satisfying points.

Method 1: Web Console Creation (Good for a first try)

Open the Tencent Cloud console, go to the Makers tab under EdgeOne, and you'll see a row of Agent templates: OpenAI Agents SDK, Claude Agent SDK, LangGraph, CrewAI, Deep Agents are all there, with both Node and Python versions. Each template comes with a demo and a link to the GitHub source code.

Choose a template, authorize GitHub access, and the platform will create a new repository under your account based on the template and automatically complete the first deployment. After that, pushing code to the main branch triggers a redeployment automatically. You don't have to touch the terminal at all; it's just a few clicks.

Method 2: CLI Creation (The path I ultimately chose)

I'm used to staying in the terminal, so I went with the CLI for the actual work. EdgeOne's command-line tool is installed directly from npm:

npm install -g edgeone
edgeone -v   # I installed version 1.6.14

There's a small detail for logging in: domestic accounts need to specify the site, otherwise it will prompt you to add the parameter:

edgeone login --site china

A browser window pops up for authorization, and that's it. A note on the authentication system here: after a successful CLI login, an API Token is automatically generated in the console (the edgeone-cli-auto-generated one in my screenshot is an example). If you're deploying in a non-interactive environment like CI/CD, you can also manually create one on the "Settings → API Token" page in the console and pass it to commands via the -t parameter or the EDGEONE_PAGES_API_TOKEN environment variable.

Then, four commands take you through the entire process from creation to launch:

edgeone makers create --template openai-agents-starter-node   # Generate project from template
edgeone makers link       # Link to the platform project, sync environment variables
edgeone makers dev        # Local debugging; frontend and Agent run on the same port at localhost:8088
edgeone makers deploy -n slim-agent   # Deploy to production

There's a detail I really like about makers dev: when it starts the local service, it also provides an /agent-metrics observability panel. You can see the full chain of model calls, tool calls, and latency for each conversation. It's especially useful when debugging why a tool call isn't working—this capability is built into the Makers runtime, no APM installation needed.

4. What the Project Looks Like

The directory structure generated by the template is very clean, favoring convention over configuration:

agents/               # Agent side, file-based routing
  chat/index.ts       #   POST /chat, SSE streaming conversation entry point
  _health-tools.ts    #   7 health tools (_ prefix means private module, no route generated)
  _health-store.ts    #   Health journal persistence layer
cloud-functions/      # Session management interfaces (history / conversations…)
src/                  # React frontend, deployed isomorphically with the Agent in one project
edgeone.json          # Declares framework, timeout, sandbox configuration

The web frontend and the Agent share a single project, a single deployment, and a unified domain. This is Makers' "isomorphic deployment," which saves the hassle of deploying frontend and backend separately and then configuring CORS.

Memory: Giving Each User a "Journal"

Cross-session memory is the soul of this project. My approach uses Makers' conversation storage (context.store) to create a single, fixed-ID "journal" conversation for each user (slimjournal_<userId>). All weight, diet, and exercise records are appended as structured JSON. Tools in any chat window read from and write to this same journal—so no matter how many new conversations a user opens, the data is always the same single source.

Tools: Model Estimates, Tools Record

Take the log_meal tool for logging diet as an example. The parameter schema is described using zod. The model passes in the estimated food list, calories, and nutritional levels, and the tool is responsible for writing to the database, aggregating the day's intake, and comparing it against the target calories.

Cards: Adding a card Event to the SSE Stream

Where does the data for the beautiful frontend cards come from? I added a layer of interception to the Agent's streaming output: if a tool's return value contains a card field, it's packaged as a separate SSE card event and pushed to the frontend. The frontend renders it by type into daily report cards, diet cards, trend cards, and plan cards. The model's text replies are only responsible for brief confirmations and encouragement, without repeating the numbers already in the cards.

5. Real-World Test on Launch Day

After launch, I used myself as the first user and ran through a full day.

In the morning, I logged my weight and breakfast in one sentence. It first called log_weight to record the weight, then called log_meal to estimate the calories for oatmeal, boiled eggs, and unsweetened soy milk item by item, booking 230 kcal. The card clearly showed high/low labels for protein/carbs/fat.

At noon, a chicken breast salad and a latte, 330 kcal. Notice the top right corner of the card: "Today's intake 560 / 1650"—it automatically added the breakfast in.

In the afternoon, I did something pretty hardcore: I clicked "New Chat" and asked it in a completely new, blank session, "How many total calories have I eaten today? How many more can I eat?" It pulled out the journal and listed 560 kcal consumed, 325 kcal burned through exercise, and about 1090 kcal remaining, missing nothing. This is the journal design mentioned earlier at work—memory doesn't belong to a conversation, it belongs to the user.

Then I asked it to set a weight-loss plan. To go from 67.5kg to 62kg, it proposed an 8-week moderate plan at 1550 kcal per day, and thoughtfully wrote a note in the card: "Losing weight isn't about speed. Losing 5.5kg over 8 weeks averages less than 0.7kg per week, which is both healthy and less prone to rebound."

In the evening, the plot got real—I couldn't resist and had two skewers of fried food and a milk tea. I was very satisfied with its reaction: first empathy ("An occasional indulgence is part of life"), then work (it logged the 730 kcal without fail), and finally recovery advice (eat more vegetables and drink more water tomorrow). It neither judges you nor indulges you.

I also tested its boundaries by asking, "Can I just eat one meal today? I want to lose 2.5 kg in a week." It gently but directly stopped me: one meal a day can easily lead to unstable blood sugar, a slowed metabolism, and rebound binge eating; losing 2.5kg in a week mostly means losing water and muscle. It then guided me to make a plan that is "scientific, comfortable, and non-rebounding." This segment is a safety boundary explicitly written in the persona prompt, and the real-world test proved it holds up.

Finally, my personal favorite feature—the weekly meal plan. A plan only gives principles, which isn't actionable enough. "What exactly should I eat every day" is the biggest execution problem in weight loss. I asked it to arrange next week's diet. It first confirmed my weight and goal, then produced two cards: a plan card, and a meal plan card with specific dishes and calories for three meals a day, Monday through Sunday, all using common, market-bought ingredients, with no repeats for seven days.

6. Three Evolutions of the UI

Let's talk about the interface, as it's quite representative of the "from template to product" process.

The template's original interface was a three-column layout: a conversation list on the left, chat in the middle, and a code panel for teaching purposes hanging on the right, showing the Agent's core implementation. As learning material, this design is very thoughtful, but as a product, it's too "demo"—users don't need to see the code.

The first cut was to remove the code panel and center the chat area. The original SSE debug stream wasn't deleted—it's genuinely useful when writing articles or troubleshooting—but was demoted to a small </> button in the top bar that opens a drawer.

The second cut was the theme. Initially, the whole site was dark mode. It was cool, but we were building a health product. Facing a pitch-black screen every day felt more like coding late at night than getting healthy. So I changed the default theme to a light color scheme of warm white and mint green, fresh and clean. Dark mode was kept, switchable with one click in the top bar, with the preference saved locally. The engineering cost was converging all the hardcoded colors scattered across components into CSS variables, allowing two themes to share one set of components.

I also did mobile adaptation along the way: the sidebar was tucked into a hamburger menu that slides out as a drawer, and cards and bubbles adapt to narrow screens. Casually sending a check-in message on a phone is the real usage posture for this kind of tool.

7. After Launch: What Else Is Available in the Console

About two or three minutes after hitting edgeone makers deploy, a new "Success" entry appears in the build list. Just a few days after launch, the build list already had seven or eight records, each one fully automatic.

A few console capabilities are worth mentioning separately:

Built-in models, free to start. New projects default to using the built-in @makers/deepseek-v4-flash from Makers Models (free for a limited time). My project's model cost from development to now has been zero. Switching models is also simple. The "Models & Keys" page in the console hosts providers like Hunyuan, Zhipu, DeepSeek, Moonshot, and MiniMax. After adding the corresponding Key, just change the AI_GATEWAY_MODEL environment variable and redeploy. Not a single line of code needs to change.

API Key. If you want to directly call the Makers Models inference service in another project, you can generate your own sk- prefixed Key in the console, using an OpenAI-compatible protocol.

Storage. Behind the conversation memory is platform-managed storage. In the console, you can see the namespaces automatically created for the project (separate for production and dev environments). Additionally, Blob and KV storage are available on demand—if I want to add food photo recognition later, there's a place to put the images.

Custom Domain. The default is a preview domain. To bind your own domain, just add a CNAME record under "Domain Management," and HTTPS is automatically configured.

8. Four Pitfalls I Stepped Into

A real project is never smooth sailing. These pitfalls can save others some time:

Pitfall 1: The limit for store.getMessages is 100. I initially passed 500, which directly threw a MemoryValidationError. It's actually written in the docs, but who reads the docs (don't be like me). The solution is to fetch the most recent 100 messages in reverse order and then reverse them back. For a check-in app, this is sufficient for a long time.

Pitfall 2: Production environment storage is eventually consistent. Everything was normal in local dev, but after launching to production, I found that when I "logged a meal and then immediately viewed the daily report," the report occasionally couldn't read the just-written record—a read immediately after a write isn't guaranteed on distributed storage. The solution is to maintain a pending list within the toolset of a single request. Records just written in this run are directly merged into subsequent read results, ensuring self-consistency within one request.

Pitfall 3: Cards disappear after a refresh. Card data travels through a temporary SSE channel, and the /history interface only stores text. A page refresh would wipe the cards. The solution was for the frontend to save a snapshot of messages with cards into IndexedDB. When restoring history from the server, it re-attaches the cards to the corresponding messages based on a content prefix.

Pitfall 4: Deployment succeeded but the page was still the old one. The new version's resources were clearly on the CDN, but the homepage HTML still had the old hash—the edge node's HTML cache hadn't expired. Waiting a few minutes fixes it automatically. If you're in a hurry, clearing the cache in the console takes effect immediately. Don't rush to doubt your build; doubt the cache first.

9. Forty Days Later

From edgeone makers create to a usable online project, the core development really only took one weekend. The rest of the time was spent polishing card styles and battling my own dinner choices. Now, its daily job is: receive my weight in the morning, a few words about three meals, and give me a daily report card at night. On the last day of the Dog Days (August 23rd), it will draw me a complete weight curve for the entire period—hopefully trending downwards. I consider this our first shared KPI.

Looking back, what impressed me most about EdgeOne Makers isn't any single feature, but that it takes over all the chores on the path of "getting an Agent online for real people to use": runtime, memory, models, observability, deployment, domains—a closed-loop platform that doesn't lock you into a framework or language and is free to start. My energy was entirely spent on the real product questions, like "how should a health coach think and speak?" This is probably the meaning of such a platform's existence.

The full implementation details of the project can't fit in this article. Interested friends can directly start one based on Makers' template and build your own version in half a day. There are still over thirty days of Dog Days left, let's get slim and beautiful together.