I recently bought a book for my kid called "Robotics for Babies."
The book starts with making a circle: first drawing with a pen, then cutting with scissors; later switching to a circle tool that produces a circle with one press; eventually moving to machines, programs, sensors, cameras, conveyor belts, and robotic arms, finally creating a robot that can automatically produce circles.
The development of Agents follows this same path.
After Large Language Models (LLMs) learned to answer, people quickly realized that just answering wasn't enough. It needs to get the latest data, open files, know if the previous step was successful, and continue processing after an error. The Claude Code, Codex, and various desktop Agents we see today are all driven by these specific problems.
What is the difference between an LLM and an Agent?
An LLM generates an answer; an Agent goes ahead and gets the job done.
If you send meeting minutes to an LLM, it will organize an action list in the chat box. If you give the same task to an Agent, it can find the meeting file itself, read the content, generate the list, write it back to the project directory, and then check if the person in charge or the deadline is missing.
An Agent also contains a model. Beyond that, it must be able to read files, call tools, remember where it left off, and write the results back. What a chat model delivers is usually a paragraph; what an Agent delivers might be a table, a modified file, or a completed task.
The same model put into different products will perform very differently. In a chat box, it mainly sees the current conversation; in Claude Code or Codex CLI, it can read files, run commands, and view errors; in the Codex desktop client, it can manage projects, save tasks, display file changes, and wait for permission confirmation.
Therefore, the gap in performance when the same model is put into different products can be huge. The difference isn't entirely in the model itself, but in what it can access, what it can call, and whether it checks its work after finishing.
On the left is an answer; on the right is a completed piece of work.
Another True Story
Last week, I installed Codex for a friend who is a doctor. He used AI before, mainly Doubao and Yuanbao. When doing information entry and academic research, he would ask AI questions, but he still had to organize the materials himself—copying the AI's answer from the chat box and pasting it into a spreadsheet or document.
After Codex was installed, he quickly gave me feedback saying it was so useful that his quota was completely insufficient, and he asked me to help him top up a $20 membership.
He didn't learn programming. The change came from Codex entering his actual workspace: it could read materials in a specified folder, call tools to process content, write results back to files, and reopen them for checking. Past AI gave him an answer, and he did the heavy lifting; the current Agent can take over a complete segment of the workflow.
This experience was very direct for me. He was already using AI that could write and summarize; what made him willing to pay immediately was that the AI could finally enter files and software to take over a piece of work.
The Model: Early AI was only responsible for answering
The most basic job of a Large Language Model is to guess what is most likely to appear next based on the preceding content. It generates one token at a time and then predicts further. A token is sometimes a character, sometimes part of a word. Articles, code, and answers are generated bit by bit this way.
The appearance of Transformer in 2017 made models better at handling the relationship between the beginning and end of a text and made large-scale training feasible. As models saw more text and code, they began to be able to write articles, do translations, summarize materials, and generate programs.
Early models were more like text completers. Later, with the addition of instruction fine-tuning and human feedback, they gradually learned to answer as requested, use specified formats, and became closer to the chat assistants we are familiar with today.
Reasoning models made multi-step problems more stable. When encountering math, code, and complex analysis, they make more judgments before giving results. Although the models became stronger, their ability still stayed at the generation layer: they cannot see files on the user's computer, don't know the latest news, and have no permission to open emails or modify spreadsheets.
This also explains why models confidently say the wrong things. What they generate is a smooth piece of content within the current context, without automatically verifying it against original sources. If names, years, and paper titles lack source constraints, several similar pieces of information might be spliced together.
As context windows lengthen, models can see more material at once. But windows still have boundaries. The longer the task, the more space files, tool results, and historical steps occupy. The system also has to decide which content to keep, which to summarize, and when to go back to the original file to reread.
In the research paper project we will build later, at this stage, we only have a "summary assistant." Copy a summary to the model, and it can organize the title, research subjects, and main conclusions. But the next paper still requires a person to find it, and the table still needs to be built manually.
The output of the model is generated token by token.
Tools and APIs: Models begin to call real data
Knowledge memorized by models through training becomes outdated. Weather, orders, calendars, and paper databases are constantly changing. To obtain this content, corresponding software services must be accessed.
An API is an interface left by software for external programs. A weather service API receives a city and date and returns temperature and rainfall; a calendar API receives time, title, and participants to create a schedule. A Tool organizes these capabilities into instructions that the model can understand: what this tool can do, what information it needs, and what results it will return.
When a user asks "Will it rain in Hangzhou tomorrow?", the model first selects the weather tool from the tool list and submits "Hangzhou" and "tomorrow." The program carrying the Agent checks permissions, accesses the weather API, and sends the results back to the model. Only after reading the real weather data does the model organize the answer.
In this process, the model is responsible for selecting tools, filling in information, and understanding the returned results; the program is responsible for internet connection, managing keys, and executing actions. The model won't suddenly gain access to email and databases just because it can call a weather tool.
In 2023, ChatGPT Plugins and function calling brought this method to more developers. Search, calculators, email, calendars, and databases began to be registered as tools the model could choose.
Whether tool descriptions are well-written directly affects the Agent. If a tool only says "query data," it's hard for the model to judge when to use it; if it's written as "query customer orders" with explanations of order numbers and time ranges, the selection will be much more stable. The same goes for error messages. "Execution failed" cannot guide the next step, while "Order does not exist" and "Current account has no permission to query" will lead the Agent to take different actions.
The research paper project at this stage can access the PubMed retrieval tool. The model organizes research questions into search terms, the tool retrieves PMID, author, year, and abstract, and the model then understands the abstract. The source is retrieved by the tool, and the content is summarized by the model.
Tools and APIs allow models to get the latest results outside of training data.
Agent Loop: Finish one step, then look at the next
A single Tool call can only complete one action. Real work often requires many consecutive actions: find materials, read content, continue searching after finding missing items, generate a table, and finally reopen it for checking.
The Agent Loop refers to this process: look at the current situation, take an action, get the result, and then decide the next step.
ReAct, proposed in 2022, interleaves reasoning and action. If a search has no results, the model can change keywords; if a command fails, it reads the error; after a file is generated, it can reopen it to see if the content meets requirements.
Task progress must be saved in the loop. The Agent needs to know which files have been read, which steps have been completed, and which questions are still pending. As tasks get longer, old processes are compressed into summaries, while key results are retained.
Plans also change. Originally planning to write a report after reading three materials, if the second material shows a conflict, the Agent should add a step to verify the source. The plan provides direction but doesn't lock it into a fixed route.
The loop also needs to know when to stop. Writing a file only means the save was successful. If the completion standard is "all 12 materials covered, duplicates merged, missing fields marked," the Agent must reopen the result and check item by item. If it encounters a conflict it cannot judge, it should stop and find a human.
Auto-GPT in 2023 already had this form of continuous action. At that time, it often forgot goals, searched repeatedly, and carried errors forward. Loops allow models to keep doing, but they can also amplify a single misjudgment continuously. Only after the model, tools, context, and stop conditions became stable did Agents gradually move from demos into daily work.
The research paper project will also run along this loop: read local materials, search when information is missing, organize fields, generate tables, and then check for duplicate PMIDs, empty fields, and broken links. If a problem is found, go back and fix it, and only end after meeting the requirements.
If the result is unqualified, go back and do it again—this is the Agent Loop.
Files, Terminals, and Screens: Agents finally have a workspace
A chat model sees what the user pastes into the chat box. After an Agent enters the file system, it can find materials itself, open files, and save results to a specified directory. After entering the terminal, it can also search for content, convert formats, process tables, and run checks.
Every action in the terminal leaves a result. Whether a command succeeded or failed, which file was not found, how many rows the table has—this information can return to the Agent Loop. The Agent no longer relies on guessing; it starts adjusting based on real feedback.
Some software does not have open APIs. In 2024, Anthropic released the public beta of "computer use," allowing models to move the mouse, click buttons, and type text based on screenshots. In 2025, OpenAI's Operator and Computer-Using Agent also showed similar directions.
Screen operations can cover more legacy software, but stability is lower than APIs. Buttons changing positions, web pop-ups, and login failures can all interrupt tasks. When an interface is available, prioritize getting structured results through the interface; only let the Agent operate the screen if there is truly no interface.
The more real the workspace, the more attention permissions deserve. If an Agent sees files and web pages, it might read malicious instructions hidden within them. Project directories, sandboxes, and manual confirmation are responsible for limiting where it can go and what it can change.
The scope of the research paper project can be very small: original materials are placed in the project, results are written to a separate folder, and public information is obtained from PubMed. It has no reason to read the entire computer, nor should it touch patient data.
Files and terminals turn model answers into actual results on the computer.
MCP: Connecting Agents to external software
Every Agent encounters the same connection problem: how to connect to document libraries, databases, design tools, and business systems. In the past, every Agent had to be adapted separately. With many tools, connection and maintenance became very troublesome.
MCP was released in 2024, defining a universal connection method. An MCP Server tells Codex: what tools are here, what information each tool needs, and what will be returned after calling. After Codex connects, the model can choose appropriate tools from this list.
Behind MCP is usually still an API. The API is responsible for actually querying or modifying data, while MCP is responsible for handing these capabilities to the Agent in a unified way. It doesn't make plans for the model, nor does it decide permissions for the user.
A single MCP connection center can hand multiple external tools to the Agent.
After connecting to MCP, the tools themselves still need to be well-made. Returning tens of thousands of rows of irrelevant data makes it hard for the model to find the key points; writing tools without previews and confirmations carries a high risk of misoperation. Return ranges, error descriptions, and permission designs all affect the final result.
When papers are all in the local project, Codex's built-in file and network capabilities are sufficient. If materials are in Google Drive, Notion, or other external systems, then connect via plugins or MCP. Tools should increase with the task; there's no need to connect all services at the beginning.
As models connect to more things, Agents have become what they are today.
Claude Code and Codex CLI: Why Agents first succeeded in code
In 2025, products like Claude Code and Codex CLI made programmers clearly feel the change. When a user submits "find the cause of the login failure, fix it, and run the test," the Agent will search the project, read files, modify content, and then execute the test. If the test fails, it reads the error and continues modifying; only after the test passes does it submit the changes for human review.
Code projects are very suitable for early Agents. Materials are all in the repository, and the terminal already has search, edit, run, and test tools. Clear error messages are generated after program execution, Git Diff can be viewed before and after modification, and if the direction is wrong, it can be restored using version records.
When a regular chat model writes a piece of code, you only know if it can run after a person copies it out. A coding Agent can execute it on the spot, and if it sees a missing module or a test failure, it goes back to the file to modify it. This dense feedback makes it easier to complete long tasks.
Code later became a general tool for Agents to handle other work. When organizing materials, it can temporarily make an extraction tool; when processing tables, it can check for null values and duplicates; when making web pages, charts, and courseware, code is responsible for batch processing, and the user gets the final file.
In February 2025, Claude Code was released as a research preview. In April, OpenAI released Codex CLI; in May, the Codex cloud Agent went online. Models, files, terminals, and feedback were put into the same workspace, and Agents finally had a work environment that was easy to execute, easy to check, and easy to recover from after an error.
From CLI to Desktop: Ordinary people also start using Agents
CLI is natural for programmers, but it's hard for ordinary people to judge from a screen of commands where the Agent has reached, what it has changed, and what permissions it needs next. Agents can already handle a lot of work, but the entry point is still technical.
In February 2026, the Codex desktop client was released. Projects, tasks, file modifications, product previews, and permission approvals were put into a workbench. The unit seen by the user also changed from "one round of chat" to "one task": a task can run for a long time, call tools continuously, and finally leave files, modification records, and items to be confirmed.
The desktop client does much more than just give the CLI a new interface. It lays out for the user which project the task belongs to, what the Agent is processing, which files have been modified, which operation is waiting for authorization, and where to view the products.
The desktop client spreads out the work process in the terminal for people to see.
Multiple tasks can also run separately. One organizes materials, one verifies citations, and one generates web pages, each retaining its own context and file changes. People don't have to watch every step and can still understand where each result came from after returning.
The same project can hold multiple tasks simultaneously, each with its own progress and context.
Claude Code, Codex CLI, Codex Desktop, Claude Cowork, and WorkBuddy show the same product line: Agents moving from the terminal to ordinary people's files and office software. The standard for evaluating it has also changed from "how well it answers" to "whether the work can be steadily delivered."
Why is the same model so much better in Codex?
What a chat box gets each time is mainly the text in the current conversation. After Codex opens a project, it can also see the files in the project, the rules left before, and the results just returned by the tools.
After it modifies a file, it can reopen it; after making a table, it can check the number of rows and null values; if it fails to run, it can directly read the error. The model doesn't have to guess "it should be fine now" because the computer will tell it the result.
Codex also saves each task separately. One task organizes materials, and another verifies citations; the two tasks won't be squeezed into the same long conversation. Which files have been modified and which operations require authorization can also be seen in the interface.
Some in the industry call this set of things wrapped around the model a "Harness." You don't have to remember the name for now. Just remember one thing: the model decides what to do next, and Codex is responsible for bringing files, tools, permissions, and execution results to it. Without this latter part, even the strongest model can only give suggestions across a chat box.
Practical: Use Codex to make a research paper organization Agent
Next, we will continue with the work of the doctor friend. The goal is clear: put in several public papers or abstracts, and Codex will organize the title, author, year, research subjects, main conclusions, and original source. Content that cannot be found is left blank; making up an answer is not allowed.
The research paper Agent we are about to build is such a pipeline from materials to results.
Set up the project first
Create a new "Research Paper Organization" folder on your computer, then open it with Codex. Create a new task and send this to it:
~~~text
Please create three folders in the current project:
Original Materials: Save papers, abstracts, and literature export files
Organized Results: Save tables and to-be-confirmed lists
Reference Templates: Save table samples that I approve
Only create folders, do not process materials.
Do not modify files in "Original Materials."
~~~
After creating them, put three to five public materials into "Original Materials." A small number makes it easier to check the first round of results.
Let it run completely once
Switch the task to Plan mode and let Codex look at the materials first and say how it plans to do it:
1Read all files in "Original Materials" and organize a paper index.23The table should include: Title, Author, Year, Research Subjects, Main Conclusions, Original Filename, and Source Link. Merge duplicate papers.4Information not clearly stated in the original text should be marked as "To be confirmed"; do not speculate.5Save results to "Organized Results"; do not modify original files.6Give a processing plan first. The plan should list the files you identified, the files you prepare to generate, and how you will check for omissions after completion.78Wait for my confirmation before executing.
Open the generated file directly to see. If five materials were input, the table should correspond to these five; whether duplicates were merged can also be seen from the title, DOI, or PMID. Check at least two main conclusions against the original text. If "To be confirmed" was filled with a definite answer, tell Codex to delete it and re-check the entire table.
This version does not connect to MCP or create Skills. First, confirm that Codex can run the basic process smoothly using only local materials.
If bibliographic information is missing, add the PubMed tool
Local abstracts often lack years, journals, or PMIDs. Searching manually every time is slow, so you can let Codex make a PubMed retrieval tool for the current project.
1The current project lacks public literature retrieval capabilities.23Please first research PubMed's official public interface, then create a retrieval tool for the current project.4After entering a research question, paper title, or search term, return: PMID, Title, Author, Year, Journal, Abstract, and PubMed original link.5Maximum 20 records per call.6Keep missing fields empty; do not speculate. The tool only reads and writes within the current project.78Give a plan first, explaining what new files will be added and how to test.910Wait for my confirmation before creating.
No need to write code yourself here. Codex will complete the implementation. After the plan comes out, mainly look at three things: whether the data comes from PubMed, whether the tool will run outside the project, and whether it will clearly say "no results" upon failure.
Let it retrieve three records using a public search term. If all three PMIDs can be opened and the titles and years are correct, this tool can be put into the subsequent process.
Write unchangeable rules into AGENTS.md
Requirements in chat can easily be scattered across different tasks. Codex reads AGENTS.md in the project, so you can put long-term rules there:
1Please create AGENTS.md in the project root directory and write the following rules:23Only process public papers and files I put into "Original Materials."4Do not touch patient data; do not generate diagnostic or treatment suggestions.5All conclusions must be traceable back to the original abstract or source link.6Write "To be confirmed" for missing information; fabrication is prohibited.7Original files are read-only; results can only be written to "Organized Results."8Check the number of files, duplicate PMIDs, empty fields, and broken links before delivery.910After writing, reopen AGENTS.md and repeat the content to me.
From now on, when creating a new task in this project, Codex will read this file first. If rules change, modify AGENTS.md directly; no need to repeat them in every conversation.
AGENTS.md follows the project, and Skills leave reusable methods.
If materials are in external software, connect Plugin or MCP
If papers are already downloaded to the project, continue using local files. If materials are in Google Drive, Notion, or a team document library, then consider connecting external services.
Codex's Plugins page allows you to search for existing plugins directly. Open the plugin details, see what Skills, connectors, or tools it brings, and then decide whether to install it. When account authorization is required, the authorization page will list the scope it can read.
Codex's Plugins page.
When there is no ready-made plugin, you can open "MCP servers" in "Settings" and select "Add server." Services running on the local machine use STDIO, and services connected via URL use Streamable HTTP. After saving and restarting, type /mcp in the input box to check if the server is connected.
Two common connection methods for MCP.
MCP is connected to real files and accounts, so don't just copy addresses from posts. First, confirm the provider, then look at the permissions and tool list. If this paper project only uses local files and PubMed, you don't need to connect to MCP at all.
Save this approach as a Skill
After running the previous process a few times, you can save it as a Skill. Later, when you change to another research question, you won't have to re-explain fields, deduplication methods, and check requirements.
In a new task, enter $skill-creator, then send:
1Please turn the research paper organization method that has been successfully run in the current project into a Skill.23It needs to complete:4Check files in "Original Materials";5Organize Title, Author, Year, Research Subjects, Main Conclusions, and Source;6Merge duplicates by PMID and DOI;7Call the PubMed tool in the project when bibliographic information is missing;8Generate a paper index and a to-be-confirmed list;9Reopen results before delivery to check for omissions, duplicates, and broken links.10Project boundaries continue to follow AGENTS.md.1112Generate a Skill draft first, and wait for my confirmation before saving.
Skills can be called again in new tasks.
After the Skill is saved, open a new task, type $ in the input box, and select the research paper organization Skill you just created. Then put in another batch of materials and only write the research question for this time:
1Organize this batch of files in "Original Materials."23Research question: What are the public research clues between sleep duration and hypertension?45After completion, leave the paper index and to-be-confirmed list in "Organized Results."
If the new task can automatically read AGENTS.md, organize materials by fixed fields, call the PubMed tool when information is missing, and put the results in the specified folder, this set of Agents is already reusable.
Next time you change topics, replace the files in "Original Materials," write down the new research question, and you can continue. Table organization, source completion, and duplicate checking are handed to Codex; whether the paper is reliable and whether the conclusion can be used for research is still judged by humans.
OK, congratulations! By now, you have run through all the basic Agent functions.
I am Miles, an AI algorithm expert who transitioned from a big company to FDE. I have done algorithm R&D, optimization deployment, and enterprise training. Follow me @miles_mazy, let's grow together and make money together.
![30-дневный план освоения Microsoft Copilot для офисных сотрудников [Основное руководство]](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1787764104479_8gytqs_HQlIHryaAAAFFJB.jpg)
