There are usually three starting points:
\nWe will begin with a few settings so you can see what each one does. Use the same approach to check a template or a generated configuration.
\nFirst we will build a topic assistant that answers from supplied materials, then cover decisions and scheduling, tool execution, background operation and real-time voice. For your first build, choose one small, checkable task: answering questions about an event's time, fees and eligibility, for example. Once those answers pass inspection, consider connecting registration or personal-record tools.
\nDecide where the finished agent will run and who will use it. A question-answering assistant might be a chat page opened through a link. An agent inside a workflow might be one processing step. A background task needs an unattended execution entry point. Choose a platform for these uses. Section 1 covers creating a dedicated assistant within a platform and configuring knowledge for an existing agent.
" }, { "id": "course-agent-building-topic-1", "title": "1. Build a topic assistant with a knowledge base", "url": "https://ai-knowledge-map.com/en/software/agents-automation/agent-building/#course-agent-building-topic-1", "html": "Open ChatGPT on the web, click the three dots on the left and select GPTs.
Click Create at the upper right, then choose to create a plugin or a GPT; the latter option is being phased out.
| Setting | What to provide |
|---|---|
| Name and description | Core purpose, audience, tone and answer depth. |
| Instructions | Functions, scope, operating limits and examples: what users provide, what results look like and what to do with missing information. |
| Conversation starters | Show what users can ask; examples in the instructions show how to answer. |
| Knowledge | Data sources, existing materials and the purpose of each source. |
| Tools | Enable the required capabilities; configure connections for external services. |
The principles are the same as writing a good prompt, but the configuration must handle similar tasks repeatedly across users and materials. No special format or magic phrase is required. Let's look at instructions, conversation starters, knowledge and tools.
\nSpecify what to do in each situation: ask a question, use a default or mark information as unspecified. Common situations include:
\nProvide common user questions and examples of good replies.
\nExamples should teach the model:
\nThey should also demonstrate format, tone and answer structure. Vary them so the model does not learn unintended patterns. If every example ends with a follow-up question, it may learn to always ask one.
\nSome examples use special markers:
\n<examples> and </examples> mark the beginning and end of a group.
<input> and <output> distinguish user input from an ideal reply.
Ordinary prose works too.
\nThese appear when a user starts, showing how to prompt the assistant and indirectly communicating its main function.
\nGood starters are:
\nUsually prepare at least three starters.
\nYou can describe sources, available materials and their purposes in one passage.
\nFor each source, include its name, version, access method and applicable scope.
\nExplain which material to use for which task and what information to take from it. When necessary, state what must not be inferred from it.
\nIf the knowledge settings only offer an upload button, put these instructions in the main instructions. For numerous or difficult-to-classify materials, upload a separate source guide and tell the agent when to read it.
\nIn ChatGPT's GPT builder, use Actions to connect external tools. For Enterprise users, GPT creation is due to transition to plugins after December; the plugin creation skill can help an agent connect external tools.
\nIf Actions is missing, Apps may be selected, or you may not yet have spoken to the builder's agent. Actions and the recommended model appear after the first exchange.
\nAdd credit with the tool provider where required, then connect the API key to the agent. If you cannot find the provider's API key page, ask AI to locate it.
\nA key may work across several agents and applications, but separate keys for each agent and purpose make revocation, usage tracking and permission management easier. Keep keys private: a leaked key may let someone else spend your balance.
\nIf you already use Claude, WorkBuddy or Codex, connect your materials to that agent. In addition to one-off attachments, put reusable materials in project knowledge, a library or a fixed directory.
\nAGENTS.md is a common instruction file for agents; capitalization matters. For Codex-backed chats, global instructions in ~/.codex/AGENTS.md can specify preferences and rules across projects. Other products have similar mechanisms: Claude Code uses ~\\.claude\\CLAUDE.md. These files load at startup.
For an individual project, add a project-specific AGENTS.md. Explain how to use its knowledge base and when to load each source, avoiding unnecessary reading and token use for every question.
The instruction file also takes context space. Keep it concise, clear and internally consistent. Store complex information and long procedures in separate files.
\nUsing Codex as an example:
\nAGENTS.md; add them to the existing file if there is one.For example, keep product manuals separate from writing examples:
\nknowledge/\n├── AGENTS.md\n├── product/\n│ ├── manual.md\n│ └── faq.md\n└── writing/\n └── examples.mdIn AGENTS.md, write:
For questions about product features and operations, first consult product/manual.md.\nUse writing/examples.md for style; do not transfer its specific facts to new tasks.\nCite the source file and section in answers.\nKnowledge-answering tasks in this project only read files. Editing source materials requires an explicit update request.Some older platform versions cannot directly read materials nested in subfolders. Check that the intended files are accessible.
\nWhen materials live in team documents, cloud storage or business systems and need ongoing updates, look for a suitable connector. Later tasks can then query the original system.
\n| Preparation | Details | Usual provider |
|---|---|---|
| Access account | An organizational account that can read the materials. | Organization administrator. |
| Connection | An existing connector or an organization-provided MCP/API. | Find it yourself; ask technical staff if unavailable. |
| Usage instructions | Purpose of each source, valid versions and citation requirements. | You and the business owner. |
| Test questions | Questions with known answers and matching source passages. | You. |
Instead of just asking to connect the database, provide a request such as:
\n\nI need the agent to check order status and calculate paid sales by date and region.
\nPlease provide the allowed data scope, read-only access method, field definitions and calculation rules, plus test questions for verifying results.
\nIf the organization has a query API or MCP service, provide connection settings. If direct database access is required, provide instructions for the chosen tool.
Technical staff can choose between two approaches:
\nFor a remote MCP service, follow the service connection steps. Database credentials can stay on the organization's server while you sign in with your organizational account.
\nIf direct local access is permitted, existing tools are available. Google's open-source MCP Toolbox for Databases, for example, supports PostgreSQL and other databases; consult the official PostgreSQL integration tutorial.
\nFor PostgreSQL, technical staff first need to:
\nEnforce read-only access through the database account or server, then verify the connection with a small test.
" }, { "id": "course-agent-building-topic-2", "title": "2. Build a voice agent with memory", "url": "https://ai-knowledge-map.com/en/software/agents-automation/agent-building/#course-agent-building-topic-2", "html": "Cross-conversation memory lets an agent retain your preferences, confirmed information and ongoing work in a new chat. A learning assistant might remember your progress; a writing assistant, your preferred style; a work assistant, the plan you approved last time.
\nFirst decide where to store it. Start with built-in memory for a platform assistant. Use files if you want to inspect, edit and move records yourself. Consider an external memory service if several devices or agents need shared memory.
\nIf you mainly use one product, check its built-in memory first. You usually do not need another database or service API.
\nClaude projects also have their own memory. Use account memory in project memory settings controls whether account memory is included. Information stored in one project is not necessarily used in every project. Claude's memory guide
\nClick your avatar, open Settings → Memory and check that conversation memory generation is enabled. Open a generated record to read it; use the edit icon to request changes through conversation.
\nWorkBuddy's documentation says it summarizes the day's conversations each night. A newly stated fact may not appear immediately, so account for this delay when checking it. WorkBuddy's memory guide
\nOpen Settings → Personalization and enable Enable Codex memories. Enter /memories in the current chat to check whether existing memories may be used and whether this chat may contribute to future memories. For chats involving MCP tools or web search, also check Allow memories from tool-assisted chats.
These memories are organized in the background and may not appear immediately. They use separate storage from account memory on ChatGPT's website. Check separately when moving to the web or another computer; signing into the same account does not by itself establish shared storage. OpenAI's memory guide
\nUse plain text files if you want to inspect, edit, back up or transfer records to another agent. The agent must be able to read and write local files. A chat interface that only accepts attachments cannot automatically update a file on your computer.
\nCreate memory.md in an accessible working directory. Start with three categories:
# User preferences\n\n# Confirmed background information\n\n# Ongoing workThis filename is a convention you choose. Naming a file memory.md does not make every agent read it automatically.
Add the actual path and usage rules to the project instruction file from the previous section. Adapt this example:
\nThe memory file is memory.md in the current project root.\n\nAt the start of each new chat, read it and use information relevant to the task.\nUpdate it when I explicitly say "remember," or confirm that a preference should continue to apply.\nRecord only information I have confirmed. Do not store guesses, examples or undecided options as facts.\nGive each entry a confirmation date. For temporary items, include the applicable period or completion status.\nWhen information changes, update the existing entry rather than keeping contradictory current versions.\nDelete the relevant entry when I ask you to forget it.\nReport that information is saved only after a successful write. Explain if write permission is unavailable.This example saves after an explicit request or confirmation. You can instead allow automatic organization of confirmed preferences and work progress, while retaining the rules against storing guesses and keeping conflicting entries.
\nSome products already maintain memory files automatically. Claude Code enables automatic memory by default in ordinary local sessions; use /memory to inspect settings and records. Memory is stored locally by project and does not automatically synchronize across computers. Check whether this meets your needs before maintaining another file. Claude Code's memory guide
To share memory across devices and clients, store it in an external service. Every agent must connect to that service and use the same memory scope. Enabling two products' built-in memory separately does not connect them.
\nMem0, for example, provides tools to save, search, update and delete memories, with MCP support.
\nDefine how to handle these categories:
\nConsult the original conversation or work record for a full discussion history. A brief memory entry should not also serve as a complete chat backup.
\nFor a continuous, call-like exchange in which the agent listens and speaks, you need full voice conversation support.
\nIf an existing task has no voice button, update the desktop app and its Codex host, then check account and workspace availability. Dictation and real-time voice chat are separate features; a microphone icon alone does not establish continuous conversation support. OpenAI's voice guide
\nClaude can switch between text and voice in the same conversation while preserving context. Type URLs, names and other easily misheard details when useful. Claude's voice guide
\nChoose a voice-building platform when you want to configure the voice, opening message and waiting time separately and share the assistant with others. ElevenLabs Agents, for example, provides web configuration, a test interface and website widgets.
\nSign in to ElevenLabs, open the Agents console, create an assistant and select Blank template.
\nOn the Agent page, fill in:
\nChoose a voice and adjust Speed on the Voice page.
\nFind Turn eagerness in agent settings and start with Normal. Choose Patient if users often need time to think or form longer sentences.
\nTo let users interrupt, check interruption under Advanced → Client Events. Configure waiting and interruption behavior in the actual settings; “do not interrupt me” in the prompt is insufficient. Conversation flow configuration
Use an API if you want to retain your website, character interface or existing agent. The agent must expose a callable interface, or you must be able to change its code.
\nAgent generates a final answer\n ↓\nProgram obtains the answer text\n ↓\nBackend calls a service such as ElevenLabs with text, voice ID and model\n ↓\nElevenLabs returns audio\n ↓\nBackend sends the audio to the current user's page\n ↓\nThe page's player plays itYou can ask through conversation without learning scheduling expressions first. Replace the brackets with your task details:
\nCreate a scheduled task.\nSchedule: [one-time date, or frequency, exact time and time zone].\nWork each run: [the task to execute].\nSources: [files, project, connected services or specified sites].\nScope: [objects to process, or the time period to cover].\nDeliverable: [output, save location or notification method].\nIf nothing matches: [end the run, record "no updates," or another agreed action].“Remind me to prepare a weekly report” and “read this week's records and write the report” are different requests. Include the actual work if you want it performed, rather than just a reminder.
\nDescribe the schedule and specify whether future runs should continue in the current conversation or run separately. After creation, open Scheduled to check the saved instructions, execution time and status.
\nFor local project files, use the corresponding desktop project and keep the computer and app running. Web tasks use accessible uploads or connected services; they cannot directly use a folder on your computer. OpenAI's scheduling guide
\nDescribe a recurring need in ordinary chat, or open Scheduled tasks → arrow beside New → Create from task, add the requirements and send.
\nFor manual setup, select Scheduled tasks → New and fill in:
\nAfter saving, check the card's next execution time and use Run for a test. Inspect results in run history. Pause future runs with the card's switch when no longer needed; this does not interrupt an already-started run.
\nLocal tasks depend on the computer and client. Cloud tasks run remotely but cannot directly access local files. WorkBuddy's scheduling guide
\nFor work that starts when something happens, look for supported events such as new email, new messages or repository updates. Connecting an application does not make every event available as a trigger; check the supported list.
\nEligible ChatGPT accounts can create Gmail, Slack and GitHub event tasks on the web or mobile; creation is not available on desktop.
\nConnect and authorize the application, then ask:
\nCreate an event-triggered task.\nEvent source: [account, channel or repository].\nTrigger: [new events to handle and filtering conditions].\nWork each run: [what to do with the received content].\nDeliverable: [save location and when to notify me].Check the task in Scheduled. Availability depends on plan and workspace settings. A task cannot use both an event trigger and a time schedule. OpenAI's event trigger guide
\nPut filters in the trigger settings where possible. To handle only a particular sender, configure that sender condition to avoid launching the agent for unrelated mail. Task instructions describe how to process matching events.
\nSee also the automation workflows chapter. If the product does not support the application or trigger you need, a platform such as n8n can connect when to start, who processes the input and where results go.
\nYou can use n8n Cloud to avoid local installation, or an existing organizational instance, which may require Docker. Begin with the shortest workflow:
\nScheduled or event trigger → Agent processing → Save results or notifyAdd a trigger node to a new workflow. A node is a step in the process.
\nFor scheduled runs, add Schedule Trigger.
\nAdd a rule under Trigger Rules, choose days, weeks, hours or another unit in Trigger Interval, then set the time. Check the workflow's time zone rather than assuming the server uses yours. Save and publish the workflow to activate its schedule. n8n Schedule Trigger
\nFor event triggers, select the application's Trigger node.
\nFor email, add Gmail Trigger:
\nAn agent that receives tasks all day and continues while you are away needs a continuously available execution environment. Built-in cloud features are the easiest starting point. Keep a local computer running when local software and files are essential. Deploy an independent program to a cloud platform or server when appropriate.
\nSeparate two needs: waiting for new tasks and processing them when they arrive; and continuously advancing a goal from one part to the next. Staying online only provides a place to run. Continued progress also requires the goal and progress setup below.
\nUse cloud execution if uploads, online documents, remote tools and APIs cover the task. Your computer need not stay on.
\nSelect Work on ChatGPT's website, or choose Cloud when creating a task in a supporting desktop client. Upload the materials, connect tools and state the task.
\nAccording to the official documentation, cloud Work tasks can continue after the desktop app closes, with follow-up through web or mobile. Check whether the task has completed or is waiting for information or approval. Cloud and local Work
\nIf the task reads local files or operates local tools through a connected computer, that computer must remain online. Cloud coordination does not move all its files and software to the cloud. Local access
\nIf your account has dots, you can use this persistent assistant. It has its own cloud computer, can follow up between conversations, and can pause, wake and resume as needed.
\nCreate a dot, connect the applications it needs, then describe its ongoing goal, sources, deliverables and decisions that require you. Inspect individual tasks through Activity. Access to your own computer still needs a separate connection and an online computer. Getting started, tasks and memory
\nAn existing workflow from section 3.1 can stay on n8n Cloud once published, without your personal computer running. Its agent interface, sources and tools must remain reachable too. If a step depends on a local program, taking that computer offline still affects the step. n8n Cloud
\nUse your computer when work depends on local files, signed-in sessions or software without a cloud interface. Configure its running conditions before considering another server.
\nFor WorkBuddy desktop:
\nThe setting stops preventing sleep once the task ends. It does not prevent manual shutdown or sleep. For all-day availability, check more than this one switch. WorkBuddy settings, lock-screen operation
\nFor other local agents, check sleep prevention, exit behavior and startup settings. Minimizing, closing a window and quitting can have different effects. For desktop operations, test whether the required action works while locked.
\nFor a large document collection or an ongoing project, staying online is insufficient. The agent also needs to know what to do next and when it is finished.
\nFor Goal mode in ChatGPT desktop or Codex, enter /goal and provide the goal, constraints and checkable completion criteria. Use the goal progress bar to pause, resume or change it.
This keeps work focused on a goal; it does not expand permissions or let a local program continue after shutdown or lost connectivity. The documentation recommends pausing before an expected disconnect and resuming when conditions recover. Long-running work
\nFor your own agent, require a progress file or database update after each stage, including:
\nOn restart, read and verify these records before continuing. Use the files or external storage from section 2.1, recording execution progress here.
\nLong tasks accumulate conversations, file contents and tool results. Alongside saving progress, control what enters each round. Otherwise, the task may exhaust context before finishing or struggle to find relevant evidence among old material.
\n1. Prefer built-in automatic compaction.
\nCompaction summarizes older conversation to free space. Claude Code compacts automatically near its context limit. Use /context to inspect usage or /compact to compact manually with a chosen focus.
Add Compact Instructions to CLAUDE.md to preserve the current goal, key decisions, unfinished work and verification results. Keep fixed rules in persistent instructions too, because summaries may omit details from early messages. Claude Code context
Codex CLI also provides /compact to replace older conversation with a short summary. This is a client-specific command, not a command for every chat product. OpenAI's command guide
Manual compaction suits supervised work. For unattended runs, confirm automatic context management or arrange program-controlled compaction at suitable stages. A prompt saying “compact when full” cannot replace this software capability.
\n2. Read only what the current stage needs.
\nDivide the task into stages that can be completed and checked separately. Read the files or retrieval results for the current stage. Keep full sources, detailed logs and finished outputs externally; retain summaries, key conclusions and source locations in current context, rereading originals when needed.
\nFor many documents, save each document's output separately and read those outputs for the final synthesis. All source text, tool results and editing history need not remain in one conversation forever. Anthropic's context engineering practices
\n3. Continue in a fresh context after a stage.
\nStart the new session by reading the task and latest handoff, checking existing outputs, then loading materials as needed. Files and records connect the work instead of an ever-growing chat history. Anthropic's long-running task practices use this staged approach too. Long-running agent harnesses
\nAdd to project instructions:
\nRead only the materials required for the current stage. Save detailed results in output files.\nAt each stage's end, update progress with key decisions, evidence locations and the next step.\nAt a new session's start, read the task and latest progress, then verify existing outputs before continuing.\nIf a summary leaves a fact uncertain, check the original source instead of filling it in.Around-the-clock operation provides continued availability and conditions for ongoing work. The agent may wait when finished or idle, and pause for quota limits, tool failures or human decisions. Next, configure how it handles these situations unattended.
\nIn ordinary chat, the agent can ask questions and you can correct it immediately. Unattended work needs advance decisions about what can continue, what must stop and how to hand problems back to you.
\nAdd handling rules to the task prompt or persistent instructions; in n8n, use the AI Agent's System Message. Configure permissions, approvals and timeouts in the software or tools as well.
\nSection 1.1 covered missing information and conflicting sources. Here, specify how a run ends when no user reply is immediately available.
\n| Situation | Suitable action | What to specify |
|---|---|---|
| Missing preferences that do not affect facts or actions, such as layout | Continue using agreed defaults. | Which defaults, and whether to mention them. |
| One independent batch record lacks essential fields | Skip it and process the rest. | Save its ID, missing information and unprocessed work. |
| Missing evidence determines the overall result, or the action target is uncertain | Stop dependent work. | Save completed outputs and list questions. |
| The user must choose, or a source conflict cannot be resolved | Mark pending and retain candidates. | Explain options, differences and the required decision. |
For example:
\nThis task runs unattended. Handle problems as follows:\nUse agreed defaults for missing wording or layout preferences; do not wait for these.\nIf one record lacks essential material, save its ID and reason, skip it, and continue only with independent records.\nIf the overall basis or action target is uncertain, stop related actions, save existing outputs and list questions.\nDo not count unprocessed, pending or failed items as completed.You can skip an independent record, but not evidence needed downstream. If one file is unreadable, other independent files may continue. If an entire dataset needed for totals is missing, partial figures cannot be delivered as complete statistics.
\nCheck which operations the task actually needs. Reading, drafting and formally sending can be authorized separately. A drafting task can omit send tools; a query task can use a read-only account. Enforce restrictions through tools, accounts or servers.
\nHuman approval often suits external sending, changes to important business records, deletion and actions beyond agreed scope.
\nIn n8n, add approval for selected tools:
\nWithout approval support, generate a draft, action list or pending record and notify you to continue. Specify that no confirmation means pending, with no execution. If a deadline is needed, define whether expiry cancels or escalates; silence is not approval.
\nDistinguish failure types rather than saying “keep trying”:
\nThe last case matters: a send timeout can mean either no message was sent or the receipt failed after sending. If you cannot establish the result, mark it “pending verification” instead of automatically sending again.
\nIn a node's Settings, configure Retry On Fail for suitable operations, with attempt and waiting limits. Use On Error → Stop Workflow to stop the process, or Continue (using error output) to route errors to a dedicated branch while independent work continues. n8n node settings
\nThe continuation branch must handle the error explicitly, not treat failed output as normal input. Repeated retries do not fix expired authentication. More complex recovery and duplicate prevention are addressed in workflow design.
\nFor retrieval, multiple tools or large batches, set limits on items, execution time, attempts and usage. Base the numbers on normal test runs, allowing reasonable variation. No single limit suits every task.
\nIn n8n:
\nWorkflow timeout and agent iterations limit different scopes and cannot replace each other. n8n Cloud also imposes plan-specific maximum timeouts. Workflow timeout, agent iterations
\nOn reaching a limit, report completed and remaining work without raising the budget or expanding scope automatically. Save progress by stage as in section 3.2, before a forced timeout prevents saving.
\nSection 3.1 configured output locations. Also define run status:
\n“Report generated, delivery failed” needs separate generation and delivery statuses rather than a single “completed.”
\nConfigure notifications for the task: summarize normal completion as agreed; promptly report pending decisions and failures blocking later work; retain only run records when nothing changes. Include the task name, issue summary, output or run link and your next action.
\nFor WorkBuddy local schedules, enable scheduled-task output notifications in Settings → General. Its mobile app can receive completion, approval and failure notifications from a linked computer. Notification guide
\nIn n8n, configure failure notifications separately:
\nThere are three kinds of publication:
\nCheck who can authorize publication and which third-party materials you used.
\nChoose a license when releasing source for modification and distribution. A public repository without a license does not give everyone unrestricted rights to modify and distribute it. GitHub's licensing guide
\nThe main differences among these four licenses concern proprietary modifications and when source must be provided.
\nConsider MIT if you want easy reuse and accept others building paid, proprietary products from your code.
\nFor example, someone can improve your MIT-licensed agent framework and sell proprietary software if they meet the notice requirements. MIT does not suit a requirement that modified versions remain open. MIT license and explanation
\nConsider Apache-2.0 if you accept proprietary products but want explicit treatment of contributors' relevant patents. Compared with MIT, it adds:
\nNOTICE file under the terms.It permits proprietary modifications and does not require returning improvements. Its grants and notice rules are more detailed than MIT's. Apache-2.0, sections 3, 4 and 6
\nConsider GPL-3.0 if recipients of your program or covered modifications should be able to inspect, modify and redistribute the source.
\nCorresponding source includes source and related scripts needed to modify, build and run the program. It does not automatically encompass every independent program in the company. Coverage of combined code depends on the actual combination. GPL-3.0, sections 1, 5 and 6
\nPrivate modification and use do not by themselves require publication. Running software on a server without giving users copies generally does not, through network interaction alone, require providing those users the modified source under the GPL. This is a key difference from AGPL. GPL definitions and section 2
\nConsider AGPL-3.0 for an agent server if you want others deploying modified websites or APIs to provide the modified source to users.
\nIt retains GPL-like distribution requirements and adds a network-service requirement: if you modify the program and users interact with that version over a network, prominently offer those users free access to its corresponding source. A service might provide a source download matching its deployed version.
\n“Users only visit the website; they do not download the program” does not avoid this requirement. The offer is for interacting users and need not specifically use GitHub. Running an AGPL program does not automatically require opening every other independent system on the server. AGPL-3.0, section 13 and corresponding source
\nAGPL permits commercial use and paid services. It governs source access and subsequent rights rather than prohibiting revenue. AGPL license and explanation
\nAll these licenses permit commercial use. A noncommercial requirement needs a different permission scheme and should not be called open source under the Open Source Initiative's definition. Open Source Definition
\nTo add a license on GitHub:
\nLICENSE and click Choose a license template.In a local project, create LICENSE with the full license text. A sentence saying “this project is open source” is insufficient. Do not edit license terms while retaining the original license name. Adding a license
For an online assistant, place usage instructions on its introduction page or near the entry point, usually in the root README.md for a project.
For a copyable project, also provide installation, configuration and startup steps. Replace API keys and database passwords with placeholders: .env.example, for example, should contain variable names and instructions only. Store actual secrets in the deployment platform's secret settings or server environment variables.