How to Create an AI Agent in 2026: A Step-by-Step Walkthrough (No Code Required)

Most "how to build an AI agent" content stops at the whiteboard. It'll tell you an agent needs a goal, some tools, memory, and guardrails, then leave you to figure out what any of that actually looks like on a screen. That's fine if you're a platform architect. It's useless if you just want one working agent by the end of your coffee break.

My name is Artem, I run the Writingmate blog, and I've built more of these small, single-purpose agents than I can count — an onboarding assistant that answers new-hire questions from an HR handbook, a support triage agent that reads tickets against a product FAQ, a research agent that pulls from a folder of PDFs instead of guessing. None of them needed a developer. Every one of them started from the same form.

This is that walkthrough. No architecture diagrams, no SDK, no "define your agent's ontology" nonsense — just the actual clicks, in order, to go from a blank page to an agent you can hand someone and say "use this." I'll build one with you as we go: a customer-onboarding agent for a small SaaS product, using Writingmate's custom agent builder as the example, since it's the one I know every field of by heart.

Agent vs. Chatbot vs. "Agent Mode" — Know What You're Actually Making

Before you open any form, it helps to know which of three things you're building, because people use "agent" to mean three different products and it causes real confusion.

• A plain chat answers whatever you type, with no saved instructions or files. Fine for one-off questions, useless for a repeated job.
• A saved custom agent — what this walkthrough builds — is a reusable configuration: one model, your instructions, optional knowledge files, and optional tools, saved under a name so you or your team can reopen it and get the same behavior every time.
• Agent Mode is a chat mode, not a saved card. You turn it on for one conversation when a task needs multiple steps and tool use, and the model plans its own path through it. It disappears when the chat ends.

This is also roughly the line between generative AI and agentic AI that gets asked about a lot. A generative model responds to a prompt and hands back an answer — one request, one output. An agentic setup keeps a job's context around, decides which tool to call, and can chain steps toward a goal instead of just answering once. A saved custom agent sits in between: it's agentic in that it keeps your instructions, model, and tools bundled and reusable, but it's not autonomously planning multi-step missions the way full Agent Mode does. Knowing which one you actually need saves you from over-building. If the job is "answer questions using this document, the same way, every time," you don't need autonomy — you need a saved agent.

Step 1: Open the Form and Give the Agent an Actual Job

In Writingmate, select Agents in the sidebar, then Add Agent. That opens the Add New Agent form, which is where basically every decision about the agent gets made in one screen.

Four fields matter most here:

• Name — make it specific. "Onboarding Helper" beats "Assistant." You'll thank yourself later when you have six agents and need to tell them apart at a glance.
• Model — pick one model per agent. Availability depends on your plan and workspace, and you can compare what's on offer on the models page before committing. For a support or onboarding agent that mostly needs to read documents and answer clearly, you don't need the most expensive reasoning model on the list — save that for agents doing harder analytical work.
• Description — required, and it's not just cosmetic. It's the summary shown on the agent's card, so write it like you're explaining the job to a new hire in one sentence.
• Instructions — required, and this is the field that actually shapes behavior. Good instructions state the agent's role, who it's talking to, what format to respond in, and any hard limits.

For my onboarding agent, the instructions I used were close to this: "You help new employees at [Company] answer questions about benefits, tools, and first-week logistics, using only the attached handbook. If the handbook doesn't cover something, say so and point them to HR — don't guess." That last sentence is doing more work than it looks like. Vague instructions without a stop condition are how agents start confidently making things up.

There's an Improve button next to both Description and Instructions that will rewrite what you've drafted. Use it, but read the result before saving — it's a starting point, not a final answer, and it can miss the specific constraint you actually cared about.

Step 2: Set Temperature and Context Length (and Understand What Context Length Isn't)

Two sliders sit below the identity fields. Temperature runs from 0 to 1 — closer to 0 gives you consistent, literal answers; closer to 1 gives you more varied phrasing and creative leeway. For a support or onboarding agent, I keep this low. You want the same policy answer every time someone asks about vacation days, not a creatively worded variation.

Context Length controls how much conversation and reference material the model can consider at once, ranging from 1K tokens up to the selected model's limit. Here's the part people get wrong constantly: context length is not permanent memory. It's a window. Once a conversation runs past that window, older messages fall out of it — the agent doesn't "remember" your first message forever just because you set the slider high.

This distinction matters more than it sounds like it should, and it's not just a Writingmate quirk — it's how most agent memory works right now across the industry. A recent breakdown of agentic memory research put it bluntly:

"Most agent memory today isn't memory. They are more like memos. A new paper argues that vector stores, RAG buffers, and scratchpads implement lookup, not consolidation. Agents accumulate notes indefinitely without ever [truly remembering]." — @dair_ai on X

Translation for your agent: knowledge files give it durable reference material it can pull from every time, but the conversation itself is not a growing memory bank. If you need an agent to recall facts across every future conversation, that belongs in a knowledge file, not in the hope that context length will carry it.

Step 3: Add Knowledge Files So It Isn't Just Guessing

This is the step that turns a generic chatbot into something that actually knows your specifics. Under Upload Files, you can attach reference material — policies, product docs, spreadsheets, FAQs.

A few practical limits worth knowing before you start uploading: files must be attached before you select Create Agent (they upload immediately, not after), each file can be up to 10 MB, and supported formats cover TXT, CSV, JSON, Markdown, PDF, DOCX, XLS, XLSX, XLSM, XLSB, HTML, XML, and RTF. That's wide enough to cover almost anything a small team already has sitting in a shared drive — no reformatting required. For my onboarding agent, I uploaded the actual employee handbook PDF and a one-page FAQ doc. That's it. Two files, and the agent went from generic HR platitudes to citing our actual PTO policy by name.

One thing to flag before you upload anything: these files are stored as private files in your workspace, and removing one from the form later detaches it from the agent's knowledge list — it doesn't necessarily confirm the underlying file was deleted from storage. Don't upload secrets, credentials, or personal data you wouldn't want sitting in a workspace file, and treat this step the same way you'd treat granting file access to a new hire.

Step 4: Connect Tools — and Set the Guardrails Before You Turn Them On

Under Agent Integrations, you choose what the agent can actually do beyond talking. This is usually split into Core Integrations, Canvas (document creation and editing), Image Generation (one generator active at a time), and MCP tools from any connected servers.

The instinct when you see a list of toggles is to flip on everything "in case it's useful." Don't. Enable only what the specific job needs. An enabled integration can read or change data in a connected service according to that service's own permissions — it's not sandboxed just because it's attached to a chat window.

Here's why that restraint matters in practice, not just in theory. People building agents with real tool access keep learning this the expensive way:

"[Agents] fail quietly, by spending your money while you sleep... a slow drip that had turned into £220 by the time I caught it." — r/AI_Agents on Reddit

My onboarding agent doesn't need web search, doesn't need image generation, and doesn't need any MCP server with write access to anything. It reads two files and answers questions. That's the whole job, so that's the whole tool list. If you're building something with real external actions — sending emails, updating a CRM, posting to a channel — start with read-only access, test it on non-sensitive data first, and add write permissions only once you trust the instructions to hold up.

Step 5: Add Conversation Starters, Then Actually Test It

Conversation starters are the example prompts shown when someone opens the agent for the first time. They're optional, but they do real work — they show a new user what the agent is actually for instead of leaving them staring at a blank box. For the onboarding agent, I used:

• What's our vacation policy?
• How do I set up my work laptop?
• Who do I contact about payroll questions?

Once everything's filled in, review the form — files, integrations, instructions — and select Create Agent. Then don't walk away. Open it and actually test it with a handful of real, representative questions, including a few it should refuse. If your onboarding agent can't correctly say "I don't have that information, ask HR" when you ask it something outside the handbook, that's a bigger problem than any missing feature. I always run at least one deliberately out-of-scope question before calling an agent done.

If the answers aren't right, go back to Agents and select Edit — the edit dialog uses the same fields as creation, plus Save Changes and Delete. New agents save as private by default, so don't assume yours is visible to anyone else on your team until you've confirmed how sharing works in your workspace.

Saved Agent vs. Agent Mode: Which One Actually Fits Your Task

Since the two get confused constantly, here's the side-by-side I wish I'd had before building my first one:

	Saved Agent	Agent Mode
Where it starts	Select Chat on a card on the Agents page	Select Agent from the mode control in a new chat
What's saved	A reusable configuration: model, instructions, files, tools, starters	Nothing persistent — it's a mode for one conversation
Model choice	You pick the model when creating it	The model is chosen automatically as the task runs
Best fit	Repeated work that needs the same instructions every time	A longer, multi-step task that needs planning during one session

If you're not sure which to reach for: build the saved agent first. It's the lower-risk, more predictable option, and most "I need an AI agent" requests turn out to be exactly this — one job, done consistently, not an open-ended autonomous mission.

What I Checked Before Calling Mine Done

Beyond the one deliberately out-of-scope question, here's the short list I run through on every agent before handing it off:

• Ask it the same question two different ways. If the answers contradict each other, the instructions are too vague or the temperature is too high.
• Ask something the knowledge files don't cover. It should say so, not invent a plausible-sounding answer.
• Check the tone matches the audience. An onboarding agent for new hires should sound different from an internal engineering agent, even on the same model.
• Confirm every enabled tool actually gets used somewhere in testing. An unused integration is just unused attack surface.
• Have someone else test it who wasn't involved in writing the instructions. They'll ask things you didn't think to ask.

None of this takes long — the whole build-and-test loop for my onboarding agent, from opening the form to feeling comfortable handing it to a real new hire, took under twenty minutes, most of which was writing the instructions, not clicking through the form.

Common Mistakes on a First Agent

• Writing instructions with no stop condition. "Answer questions about X" without "and say so if you don't know" is an invitation to hallucinate confidently.
• Turning on every integration by default. More tools isn't more capability if half of them are irrelevant to the job — it's just more that can go wrong quietly.
• Treating context length as memory. If the agent needs to recall something reliably across conversations, put it in a knowledge file, not in the hope that a large context window will carry it forever.
• Skipping the test step. Creating the agent isn't the finish line. An agent that's never been asked a trick question hasn't actually been tested.
• Uploading more files than the job needs. A bloated knowledge base makes retrieval noisier, not smarter. Two well-chosen files beat twenty scattered ones.

If you want to see the whole build in the platform itself rather than reading it in prose, the full field-by-field reference lives in the custom agent creation docs, and the broader picture of how saved agents differ from Agent Mode is covered in the agent selection guide.

So here's the honest summary: creating an AI agent in 2026 isn't the hard part anymore. The form takes ten minutes. The part that actually determines whether it's useful is the same as it's always been — a specific job, instructions with an honest stop condition, only the tools that job needs, and five minutes of testing before you hand it to someone else. Do those four things and you'll have an agent that works, not just one that exists.

See you in the next one!

Artem