How did I build a dedicated domain Agent?

I made something called Wild Travel Y, which is a self-driving route planning Agent.

Here's what it does: You tell it the general direction-"Set out from Chengdu, take the elderly, and want to go to western Sichuan, about five days"-it helps you determine your destination, check the real road conditions of each section of the road, calculate how long to drive every day, don't be too tired, compare the air ticket and hotel, and finally draw a line that can directly follow the departure: which day to go, where to live, how many kilometers to drive, what high altitude to pay attention to and road closures. After queuing, you can also help you find a way to get on the road with.

! 野行 Y 的规划入口

I am a heavy self-driving player myself. I designed, recruited and drove all the major ring roads such as Qinggan, Western Sichuan, Southern Xinjiang, and eastern Tibet one by one. Therefore, I am very clear about the difference between "the journey you can start" and "the beautiful words". This article doesn't write about travel strategies. It writes about how an Agent in such a dedicated field is put together as a whole-functions, layout, business, and architecture, broken down layer by layer.

Let's start with a lower-level choice: Its skeleton is the same thing as Coding Agents such as Claude Code.

The reason why the Coding Agent is easy to use is that it turns "writing code" into an Agent-a set of tools (reading files, changing files, running commands), a model-driven loop (the model decides which tool to call next), plus context management, memory, and back-and-forth confirmation. When I did Wild Trip Y, I moved this whole set as it was. I just changed the tool from "reading documents and changing documents" to "searching destinations, estimating driving times, checking aircraft alcohol, and pushing models", and changed the field from "code" to "travel".

!

So to tear down this Agent, I divided it into two clear layers.

Level 1, common architecture. This layer is a skeleton borrowed from mature paradigms such as Coding Agent. It will remain basically unchanged in a different industry. I basically follow mature practices and have not invented the wheel myself.

• Model-driven loop. This is the foundation. It is not a dead assembly line (first check air tickets, then check hotels, and then schedule every day), but a cycle: the model looks at the current situation for each round and decides which tool to adjust next until it thinks it is completed. Adjust the "submission itinerary" to finish. However, it is not enough to let the model decide freely. When it really runs, it will deviate and fail to converge. Therefore, a layer of guardrails has to be arranged in the cycle-when you have checked enough data, remove the search tool from its eyes, and before issuing a report, you must first set the main line for you to confirm it, and the self-driving journey must be calculated first. Don't set aside twelve hours a day when driving. Letting it free is a loop, and trapping it in chaos is half of the code.
• A set of tools. Every action that the model can adjust in the loop is a tool-searching for destinations, verifying road conditions in parallel, estimating driving hours for each period, checking the actual aircraft wine, recommending models, and submitting itineraries. The collection of tools defines what the Agent can and cannot do.
• Context Engineering. Everything the model knows in every round is the words fed into the window this time. It takes more than a dozen tools to adjust one wire arrangement. If every original return is piled in, the window will expand rapidly, be expensive and slow. So for high-noise returns like web search, they are slimmed down before entering the model, leaving only the title and a short summary; some are verified in parallel, and even distill a bunch of web pages into a single sentence within the tool and then come back.
• Memory. Context is the short-term memory in a session; remembering "where you have been and what you prefer" across sessions relies on a separate memory system-an old user will start a new trip and inject his portrait into it first, so that the Agent remembers this person as soon as he comes up.
• Sub-Agent and Parallel. Some tasks should not be done smoothly in the main cycle. To verify the road conditions of a batch of passes and distribute them in parallel, it is several times faster than checking them one by one. Whether the completed plan should pass, it is much more objective to have a "clean-brain" sub-agent to check the defects than letting it check itself.
• Model layer. An Agent often uses more than one model: the difficult model for heavy work and strong work, and the simple and high-frequency model for fast use. If the main force dies, there must be a free cover for the bottom and never disconnect. Below this piece is a complete set of model layering, fallback chains, and concurrency control.
• Engineering and Operation and Maintenance. Deployment, performance, debugging, and monitoring so that it does not collapse under real traffic and can be detected if there is any problem.

Second level, professional ability. This layer is unique to the field of travel. There are no ready-made answers and it is all up to you to gnaw it on yourself-it is it that determines whether the Agent understands the industry or not.

• turns business actions into tools. What exactly does "queuing up for self-driving" do? Dismantling it involves searching for destinations, verifying road conditions, estimating driving times, checking aircraft alcohol, and pushing vehicle models, each of which becomes a tool. Whether this step is accurate or not, you must understand the industry very well.
• Domain Modeling. Self-driving has its own rules: driving twelve hours a day is a disaster, and it has to be divided into two days and added accommodation in the middle; when traveling with multiple people, one cannot only care about one person, and everyone's demands must be listed and arranged on a page. Everyone can accept it. These constraints are unique to travel and must be built in one by one.
• Data authenticity. This is the lifeline of professional agents. If you can't get a real-time price for your air ticket, you will honestly mark the "reference price" and never pretend to be accurate; if you can't find the coordinates of a place name, you'd rather have one less point on the map than just point to a place with the same name. Authenticity is not a switch, it is the accumulation of a hundred such small decisions.
• Judgment layer. The most valuable data is not the specifications that can be searched, but the judgments that no one has structured. "What car should a family of six drive when taking an elderly person on the bad roads of western Sichuan?"-this sentence is not in any parameter table or API. It is the experience accumulated by one's own car. I made it into a model library: the upper half is objective parameters that can be grasped, and the lower half is the judgment of "what path is suitable and who should not choose". This half cannot be copied away.
• commercialized. Finally, turn these into something that people really use-accounts, dates, route squares, and let it grow from a tool to a product.

!

The final output of these two floors is something like this-not a beautiful sentence, but a line that marks where to live every day, how long to drive for each section, and which road conditions and high deviations to be verified before departure, which can directly follow the departure line:

! 野行 Y 排出的一份完整行程

How do these two layers fit together? I view it as a multiplication: General architecture × professional capabilities. The general architecture determines whether it can run, and its professional ability determines whether it understands the industry at all. There is nothing missing-there is only architecture but no profession, it is an empty shell covered in travel skin, and the things given cannot withstand scrutiny; there is only profession but no structure, it is a pile of dead data without engines. Moreover, the nature of these two halves is different: the general architecture can be learned and copied, and the mature paradigm has been developed; there are no ready-made answers to professional abilities, so you have to gnaw and accumulate them little by little.

!

This is the overall framework of Wild Travel Y: a two-layer structure and a dozen modules. Next, I will use this number as an example and break down each piece and talk about it in detail-how to write the cycle, how to add guardrails, how to design tools into capability boundaries, how to manage the context, how to use the architecture to cover the authenticity of data, how to layer the model layer to the bottom, and how to build the judgment layer like the model library. Each article tells a piece of it is something that has been really done and stepped on in a pit.

I'll give you the entire picture today. Next article, starting from the bottom foundation: What is going on with the "cycle" of the Agent?