30-Minute Hands-On: Building a Working AI Agent from Scratch

Skip the Theory, Let's Just Build

Explanations of the Agent concept are everywhere, but tutorials that actually get an Agent up and running from scratch are surprisingly rare. This article skips the dry theory and, through a complete hands-on demo, gives you a concrete picture of how to build a "working AI Agent" in 30 minutes using AI coding tools—essentially, creating your own specialized assistant.

The entire development process uses an AI coding tool built on a heavily customized version of VS Code (created by ByteDance). Interestingly, from start to finish, the developer barely writes a single line of code by hand. Instead, natural language instructions drive the AI through the entire process of setting up the environment, writing modules, installing dependencies, building the frontend, and fixing bugs—which is itself a vivid demonstration of "an Agent developing an Agent." The core technical pillars of such tools are Code-Aware Context and multi-turn planning capability: the tool continuously indexes the current project's file tree, dependencies, and runtime state, injecting them as implicit context into every conversation. This gives the model cross-file comprehension rather than mere completion for a single code snippet. This is the fundamental difference that sets it apart from the pure-completion mode of early GitHub Copilot.

Step 1: Let the AI Scaffold Your Agent

The starting point is extremely simple: open the tool, choose a directory, and issue a command directly—"Help me develop a simple Agent, a hello world."

What follows is almost entirely automated. The AI coding tool performs the following actions in sequence:

• Inspects the current working directory
• Creates the project files and the core agent module agent.py
• Writes a dependency list based on requirements.txt
• Automatically sets up the environment and installs the required packages
• Runs tests to verify the results

Interestingly, after completing the initial development, the tool even proactively "requests expert advice"—invoking an internal review mechanism to conduct a security assessment of the code, such as checking the security risks of eval and fixing JSON formatting issues. This shows that today's AI coding tools already possess a high degree of autonomy, capable of self-review and self-correction.

The generated Agent adopts a ReAct-style tool execution environment, based on the standard JSON format of OpenAI Function Calling. It can analyze user needs, call tools to obtain results, and then provide a final answer based on those results.

Background: ReAct and Function Calling

ReAct (Reasoning + Acting) is an Agent reasoning paradigm proposed by a Google research team (Yao et al.) in 2022. Its core idea is to have the large model iterate cyclically through three steps—"Thought → Action → Observation"—until it arrives at a final answer. Its key innovation is the deep integration of Chain-of-Thought reasoning with external tool interaction: the model not only generates intermediate reasoning steps but also dynamically adjusts subsequent reasoning paths based on the real observations returned by tools. This makes the entire decision-making process transparent and debuggable, greatly reducing the risk of hallucination propagation. Compared with pure-reasoning or pure-acting approaches, ReAct significantly reduces hallucinations and improves task completion rates, achieving state-of-the-art results at the time on multi-hop reasoning benchmarks such as HotpotQA and FEVER.

Function Calling is a standardized tool-calling interface officially launched by OpenAI in June 2023. It allows developers to declare a tool's name, description, and parameter structure in JSON Schema format. During inference, the model automatically decides whether to trigger a call based on the tool descriptions and user intent, and outputs structured call instructions (rather than natural language). This mechanism decouples "model judgment" from "tool execution": the model is only responsible for deciding what to call and which parameters to pass, while actual execution is performed by the host program, which then returns the results. This greatly reduces the engineering complexity of tool integration and makes Agent behavior more predictable and auditable. Currently, mainstream large models such as DeepSeek, Claude, and Gemini all support this standard, forming a de facto industry norm.

Core Composition of an Agent: Tool System and Memory Mechanism

From the generated project structure, we can see that a basically functional AI Agent is primarily supported by two major capabilities:

Built-in Tool System

This hello world Agent comes with three core tools:

1. Get the current time
2. Safely evaluate math formulas
3. Web search (initially a simulated function, later connected to a real search)

The tool system supports dynamic registration, meaning you can continuously add new capabilities to the Agent, allowing it to evolve alongside your business needs. The quality of tool design directly affects the Agent's overall performance—a clear tool description acts like an "instruction manual" for the model. The more accurate the description, the higher the probability the model selects the correct tool; the more streamlined the parameter design, the lower the probability of generating incorrect calls. This is why Tool Engineering is increasingly regarded as an independent subfield of Agent development.

Memory Mechanism

The Agent is equipped with both short-term and long-term memory. Short-term memory stores the current conversation history, while long-term memory retains key information. In the initial version, this data is stored only in memory and is cleared when the program exits. When asked "Where is the memory stored?", the AI proactively proposed and implemented persistent storage—writing memory to a JSON file to avoid losing conversation history after a restart.

Background: The Three Layers of an Agent Memory System

In Agent architecture, memory systems are typically divided into three layers: short-term memory (In-context Memory), which is the context window of the current conversation, constrained by the model's token limit. It is essentially a first-in-first-out sliding window—when the conversation history exceeds the token limit, earlier content is truncated and lost. Long-term memory (External Memory) achieves cross-session information persistence through vector databases (such as Pinecone, Chroma, Weaviate) or structured storage (such as SQLite, JSON files). The core advantage of vector databases is support for semantic similarity retrieval, which can recall semantically relevant historical records based on the current question, rather than simple chronological retrieval. Some advanced implementations also introduce working memory, used to temporarily store intermediate states and subtask results during complex multi-step task execution—analogous to how human working memory functions like scratch paper during problem-solving.

JSON files, as a lightweight persistence solution, are suitable for the prototype stage or low-concurrency scenarios, with the advantages of zero dependencies and direct readability. Production-grade Agents usually migrate to vector databases to support semantic retrieval, enabling the Agent to "recall" key information from historical conversations rather than merely flipping through records in chronological order. It's worth noting that memory system design must also consider a forgetting mechanism—infinitely accumulated memory increases retrieval noise. How to strategically compress, summarize, and discard historical memory is one of the frontier issues in current Agent memory research.

For lightweight applications, using a JSON file instead of a database for persistence is a reasonable engineering trade-off—simple, sufficient, and without introducing extra complexity.

From Command Line to Web: Giving the Agent an Interactive Interface

Initially, the Agent could only interact via the command line in a terminal—a rather primitive experience. So the next instruction naturally followed: use Flask to build the backend and generate a web chat interface.

The AI then created the frontend template index.html, updated the Flask application and Service layer, installed dependencies, and started the service. Very quickly, a previewable web chat interface appeared.

Background: Flask and the Layered Architecture of AI Applications

Flask is one of the most lightweight web frameworks in the Python ecosystem, adopting a microframework design philosophy with a core of only about 1,000 lines of code. It is well-suited for quickly building the API service layer of AI applications. In a typical layered architecture for AI applications, the frontend (HTML/JS) handles user interaction and streaming response rendering, the Flask backend acts as the business orchestration layer responsible for route dispatching, session management, and calling the LLM API, while the underlying Agent module encapsulates tool-calling logic and memory management. This "frontend + lightweight backend + LLM API" three-tier structure has become the de facto standard pattern for rapid delivery of AI applications, and is also the default deployment form for mainstream frameworks like LangChain and LlamaIndex.

To support streaming output (Streaming), one usually also introduces Server-Sent Events (SSE) or the WebSocket protocol, allowing the model's generated content to be pushed to the frontend in real time, improving interaction fluidity—this is the technical foundation behind the "word-by-word output" effect in products like ChatGPT. SSE is more lightweight than WebSocket, requiring only one-way server push, making it particularly suitable for LLM streaming generation scenarios; WebSocket, on the other hand, is suited for multimodal interaction scenarios requiring bidirectional real-time communication, such as real-time transcription and feedback for voice input. In engineering practice, Flask's stream_with_context combined with the OpenAI SDK's stream=True parameter can implement a complete streaming response pipeline with minimal code—this is the standard approach for frontend-backend collaboration in current AI applications.

The whole process embodies the classic layered thinking of modern application development: the frontend page handles interaction, the lightweight Flask backend connects the business logic, and the large model API provides intelligent capabilities in the background.

The Key Step: Connecting to the Large Model API

The reason an AI Agent is "intelligent" lies at its core in the large language model it calls behind the scenes. This hands-on demo connects to the DeepSeek API.

The basic process is as follows:

1. Create an API Key on the DeepSeek platform
2. Configure the Key into the project environment
3. Start the Agent and test connectivity

Several typical pitfalls were encountered during the practice, worth noting specifically:

• Wrong configuration injection location: The AI once sent the API Key directly to the model as conversation content, causing the request to fail—the injection location of the configuration must be precise.
• Test Key causing 401: Using an invalid Key returns an authentication failure; only after switching to a real Key does the connection work properly.
• Tool calls not triggered: In an early version, the Agent could not correctly return the current time. The root cause was that the model was giving a "hallucinated answer" rather than actually triggering a tool call. The fix was to mandate that operations such as calculation, time, and search must be executed through tools, preventing the LLM from "making up" answers on its own.

Background: The Hallucination Problem and Forced Tool-Calling Strategies

"Hallucination" in large language models refers to the model generating content that seems reasonable but is actually incorrect or fabricated. This problem is especially prominent when dealing with real-time data (such as the current time or the latest stock prices) or precise calculations. The root cause is that an LLM is essentially a statistical language model—its "knowledge" comes from the probability distribution of the training data, not the real-time world. When generating a response, the model follows the principle of "the highest-probability next token," lacking metacognitive awareness of the boundaries of its own knowledge. Therefore, it tends to "confidently guess" rather than "admit it doesn't know."

In Agent development, common engineering strategies to address hallucination include: explicitly stipulating in the System Prompt that certain types of questions must be answered through tool calls, and using counterexamples to illustrate scenarios where direct guessing is prohibited; using OpenAI's tool_choice: required parameter to force the model to output a tool call rather than directly generate an answer (applicable to scenarios where tool use is known to be required); and introducing a verification layer to perform post-hoc validation of model output, for example using a code executor to verify whether the calculation result matches what the model claims. A deeper solution is to build a Tool-First Agent architecture, forcibly routing all questions involving factuality, timeliness, and precision to tools, with the LLM responsible only for language understanding, intent recognition, and result expression. This is also a direction continuously tracked by specialized evaluation benchmarks such as AgentBench and ToolBench.

This detail highlights one of the core challenges of Agent development: how to ensure the model correctly calls tools rather than generating hallucinated answers that seem reasonable but are actually wrong.

Testing and Iteration: Making the Agent Actually Work

After the fixes were completed, the actual effects of the three major tools were verified one by one:

• Get time: Correctly returns the current time
• Math calculation: "34 times 35" quickly outputs an accurate result
• Web search: Performs a real search and returns real-time information

There is an industry insight worth noting here: with Agents, the moat of traditional search engines is being eroded. By using Python to directly scrape web data and then handing it to a large model for aggregation, it is entirely possible to build your own "private search engine," no longer heavily dependent on traditional search services like Baidu or Google.

Background: The Substitution Effect of Agents on Traditional Search Engines

The erosion of search engines' moat by Agents has already drawn widespread attention at the industry level. The business model of traditional search engines relies heavily on "display ads + paid ranking," and its commercial closed loop is built on the premise that users must click on the search results page. When an Agent directly scrapes raw data via API and has a large model aggregate it into a structured answer, users no longer need to browse the results list, and the commercial logic of ad display is fundamentally overturned. According to Gartner's forecast, traffic to traditional search engines may drop by more than 25% by 2026.

Perplexity AI, OpenAI's SearchGPT, and the self-built search capability demonstrated in this article all represent different implementation paths of this trend. From a technical implementation standpoint, an Agent's search capability is usually achieved through professional search interfaces such as SerpAPI, Tavily, and Bing Search API. Among them, Tavily is a search API optimized specifically for LLM Agents, automatically preprocessing raw search results (removing ads, extracting body text, sorting by relevance) to reduce the LLM's burden of processing noise; the large model then semantically distills multiple raw results and finally outputs a denoised direct answer. The information density of this process is far higher than the traditional "blue links" model, which explains why Google accelerated the rollout of the AI Overviews feature in 2024 to counter this impact, and why Microsoft deeply integrated Bing with Copilot—traditional search giants are being forced to reconstruct the core product form of their offerings with AI.

In addition, the interface can be continuously refined—features like dynamic backgrounds, message animations, and voice input are all essentially achieved through ongoing iteration on index.html.

From Demo to Enterprise-Grade AI Agent

Although this hello world Demo is simple, it clearly outlines the deployment path for enterprise-grade Agents:

If a company has a sufficient budget, it can fully deploy DeepSeek or a similar large model privately on-premises, transform this Agent framework into an enterprise-exclusive assistant, and connect it to various internal software and business systems—equivalent to having a "dedicated intelligent assistant inside the company."

Compared with directly purchasing commercial products, the cost of this approach is mainly concentrated on API tokens or model deployment, while data security and system controllability are both better guaranteed. On the enterprise deployment path, this architecture can further evolve into a multi-Agent collaboration system—for example, a "planning Agent" responsible for task decomposition, multiple "execution Agents" processing subtasks in parallel, and then a "summary Agent" integrating the results.

Background: The Technical Landscape of Multi-Agent Collaboration Frameworks

Multi-agent collaboration represents an important direction in the evolution of Agent architecture from a single instance to a distributed system. Currently, mainstream frameworks have formed two main paradigms: In the centralized orchestration (Orchestrator-Worker) model, a master control Agent holds the global task view, responsible for decomposing tasks and assigning them to specialized sub-Agents. AutoGen (Microsoft) and LangGraph adopt this approach, with the advantage of a clear control flow that is easy to debug. In the decentralized collaboration (Peer-to-Peer) model, multiple equal Agents negotiate the division of labor through message passing. CrewAI and MetaGPT are typical representatives, closer to the collaboration model of a real team.

The core challenge of multi-Agent systems lies not in technical implementation but in the design of communication protocols between Agents and the division of task boundaries—blurred responsibilities lead to duplicate execution or omission of key steps, while overly fine-grained decomposition causes significant communication overhead and loss of context. When deploying in enterprises, it is usually recommended to start with "a single Agent + a rich tool set" and introduce a multi-Agent architecture only after clearly identifying bottlenecks, rather than pursuing architectural complexity from the outset. The Model Context Protocol (MCP) proposed by Anthropic in 2024 is also attempting to establish a standardized protocol for multi-Agent communication—engineering standards in this field are still evolving rapidly.

Conclusion: Software Development Is Moving from "Handicraft" to "Automated Industry"

The biggest takeaway from this hands-on practice is not how complex an application was built, but that it clearly reveals a profound trend: the barrier to AI Agent development is dropping dramatically.

In the past, writing software was like forging by hand—a programmer producing dozens or a hundred-odd lines of code in a day was considered highly productive. Today, with AI coding tools, generating thousands or even tens of thousands of lines of code in a single day has become reality. Software development is accelerating its shift from "labor-intensive" to "technology-intensive," from manually typing code to intelligent automatic generation. The economic implications of this shift are equally profound: the marginal production cost of software approaches zero, and the competitive barrier will migrate from "whether you can write code" to "whether you can define clear requirements and evaluation criteria"—that is, from execution ability to judgment ability.

For developers, rather than agonizing over "what the underlying principles of Agents are," it is better to get hands-on quickly and proactively adapt to this new era where "traditional frontend-backend development models gradually evolve and AI Agent development becomes mainstream." Mastering the engineering mindset of Agents—understanding tool system design, memory architecture selection, and hallucination control strategies—will become the core competitiveness of the next generation of software engineers.

Key Takeaways

• ReAct + Function Calling is the technical foundation of current mainstream Agents; the former provides the reasoning paradigm, the latter provides the tool interaction standard
• Tool description quality directly affects Agent performance; clear and accurate tool descriptions are a key engineering detail
• Layered memory system design: use JSON files in the prototype stage, and migrate to vector databases in production to support semantic retrieval
• Hallucination control is the core engineering challenge of Agent development; a tool-first architecture + system prompt constraints are the main countermeasures
• Multi-Agent collaboration is best started with a single Agent, introducing more only after bottlenecks are clear, to avoid introducing unnecessary architectural complexity prematurely
• Agents are reshaping the commercial logic of multiple core industries such as search and software development; developers' competitive barriers will shift from execution ability to judgment ability