How to Create an AI Agent by Describing It: The 2026 Guide

Two years ago, creating an AI agent meant one of two things: writing code against a model provider's API, or dragging boxes around a visual canvas until the flowchart did roughly what you wanted. Both approaches had the same problem. They forced you to translate a plain idea, "watch my inbox and flag anything from a paying customer," into a technical artifact before you could find out whether the idea was any good.

That translation step is now optional. On platforms like Skopx, you create an agent by describing it in a chat. You type what you want in ordinary language, the chat assembles the agent, and you review what it built before anything runs. No code, no canvas.

This guide walks the full path from a sentence to a running autonomous agent: writing instructions, choosing a trigger, setting permission grants, capping budgets, watching the first run, and iterating on what you learn. The examples reference how Skopx's Create Agent workspace does each step, but the underlying decisions apply to any serious agent platform.

What you are actually creating

Before the how, it helps to be precise about the what. An agent is not a chatbot and it is not a workflow. If those distinctions are fuzzy, the companion pieces on what an autonomous AI agent actually is and how agents differ from workflow automation cover them in depth. The short version:

• A chatbot responds when you talk to it and does nothing when you stop.
• A workflow executes a fixed sequence of steps you designed in advance. Same input shape, same path, every time.
• An agent receives a goal, then decides at run time which tools to use and in what order to reach it. The path can differ between runs because the world differs between runs.

That flexibility is the point, and it is also why the rest of this guide spends so much time on constraints. An agent that decides its own steps needs boundaries you set deliberately: what it may touch, what it must ask before doing, and how much it may spend trying.

A well-formed agent, in Skopx's anatomy, has six parts:

Every step below fills in one of these parts.

Step 1: Describe the job in one honest paragraph

Open the chat and describe the agent the way you would brief a new hire on their first day. Not a spec. A briefing.

A concrete example, clearly hypothetical: suppose you run support for a small SaaS product and you want help with inbox triage. A good first description looks like this:

"Every weekday morning, go through unread emails in our support inbox. Label each one urgent, normal, or ignorable. Urgent means a paying customer reporting something broken, or anyone mentioning a refund or cancellation. Draft replies for the normal ones but do not send anything. Post a summary to the #support Slack channel."

Notice what this paragraph contains: a schedule ("every weekday morning"), a scope ("unread emails in our support inbox"), a decision rule ("urgent means..."), an output ("draft replies", "post a summary"), and a hard boundary ("do not send anything"). Those five elements are the skeleton of every good agent description.

In Skopx, the chat takes this paragraph and assembles the agent from it: it drafts the instructions, proposes a trigger, identifies which toolkits the agent needs (Gmail and Slack here), and surfaces all of it for your review. The workspace shows every agent you own in a rail beside the one you have open, so as your collection grows, each agent stays one click away.

What you should not do at this stage is over-specify. You will iterate after the first run anyway, and long speculative instructions written before you have seen the agent work tend to encode guesses rather than knowledge. Start with the honest paragraph. Expand it when reality tells you where it was thin.

Step 2: Refine the instructions, because they are the product

The instructions are the agent. Everything else, triggers, grants, budgets, exists to control when and how the instructions execute. So it is worth learning to write them well, and worth knowing they are editable and versioned, so no revision is ever destructive.

Three properties separate instructions that work from instructions that flail:

Decision rules over vibes. "Flag important emails" forces the model to invent a definition of important on every run, and it will invent slightly different ones. "Flag emails from domains that appear in our Stripe customer list" is a rule the agent can apply consistently. Wherever you catch yourself writing a judgment word (important, relevant, significant, urgent), ask whether you can replace it with a testable condition. Sometimes you cannot, and delegated judgment is genuinely what you want. But make that choice deliberately.

Explicit negative space. Agents fail more interestingly in what they should not do than in what they should. "Never send email, only draft" and "do not contact anyone outside the company" are the sentences that let you sleep. Write them down even when they feel obvious, because what is obvious to you is not in the instructions until it is in the instructions.

An output contract. Say exactly what the run should produce: a Slack message with a specific structure, a set of drafts, rows appended to a sheet. Runs in Skopx end in a markdown report rendered as a document, so a clear output contract also makes every report instantly scannable.

There is a longer treatment of this craft in the guide to writing agent instructions, including patterns for edge-case handling. For now, the test is simple: could a competent temp worker execute your instructions without asking you a question? If not, an agent probably cannot either.

Step 3: Choose the trigger

An agent needs to know when to run. There are three options, and the right one falls out of the job description almost automatically:

• Manual ("runs when you ask"): you start every run yourself. This is the correct trigger for every new agent regardless of its eventual destination, because you want to be watching the first several runs. It remains the right permanent choice for jobs that respond to your judgment, like "research this account before my call."
• Schedule: the agent runs on a recurrence like "Every Monday at 9:00 UTC." Right for digest, monitoring, and hygiene jobs, anything defined by cadence rather than by events. Details and pitfalls in the piece on scheduled agents.
• Webhook: an external system starts a run by hitting a URL, so the agent reacts to events, a new form submission, a payment failure, within moments rather than at the next scheduled tick. One caution that matters for security: treat the webhook payload as untrusted data the agent examines, never as instructions it obeys. Skopx enforces exactly that.

For the support triage example, the schedule is right: weekday mornings, before the team starts. But you would still create it as manual first and promote it to a schedule after a few supervised runs. Triggers are settings, not commitments; changing one later takes seconds.

Step 4: Grant tools, at the right permission tier

Here is where agent creation differs most sharply from workflow building. In a workflow, each step names its exact action, so permissions are implicit in the design. An agent chooses its own actions, so you must decide, per integration, how much it may do without you.

Skopx connects to nearly 1,000 integrations through its toolkit catalog: Gmail, Slack, Notion, HubSpot, Salesforce, Google Sheets, GitHub, Linear, Jira, Stripe, Shopify, and the long tail beyond. You can browse the full set on the integrations page. When you create an agent, you grant it access to specific toolkits, and each grant carries a tier:

The default posture worth internalizing: reads flow, writes ask. Under "asks first every time," read operations still proceed without interruption, so the agent can gather everything it needs; it is the write-shaped actions that stop and wait for you. When an action parks for approval, you see the exact call and its exact arguments. Approving executes precisely that parked call, once. Rejecting executes nothing. Approvals can also expire, so a stale pending action from last Tuesday cannot fire into a world that has moved on.

For the triage agent: Gmail granted in drafts-only mode (it labels and drafts, it never sends), Slack at "asks first every time" until you have seen a few summary posts and are happy to promote it to automatic. The deeper design space here, including when human approval is a feature rather than a bottleneck, is covered in agents with human approval.

Step 5: Set budgets before the first run

An autonomous system needs a defined worst case. Budgets are how you set one, and you should set them before the first run, not after the first surprise.

Skopx exposes four caps per agent: tokens per run, tokens per day, maximum steps per run, and a minute cap on run duration. Together they bound every axis on which a run could grow: cost, total daily cost, decision count, and wall-clock time. If a run hits a cap, it stops. If an agent fails on budget three times, it auto-pauses entirely and waits for you, on the theory that three consecutive budget failures indicate a problem worth a human look, not a limit worth raising blindly.

How to choose numbers with no history: start tight. A tight budget that truncates an early run costs you one rerun and teaches you the agent's real appetite. A loose budget teaches you nothing and covers pathological behavior, like an agent retrying a failing call forty times, in silence. After a few runs you will know the typical token count and step count from the run reports, and you can set caps at a comfortable multiple of typical.

One structural note that helps with budgeting: agents with memory get cheaper after the first run. The first run of a monitoring agent surveys the whole landscape; subsequent runs read the cursor or baseline stored in memory and process only what changed, producing delta reports. Expect run one to be your most expensive and size the per-run cap for it, then watch the dailies settle.

Step 6: Define success criteria

Most people skip this step, and it is the difference between an agent you supervise by reading everything and an agent you supervise by exception.

Success criteria are your statement of what a good run looks like: "every unread support email got a label," "the Slack summary lists counts by category," "no email was sent." In Skopx, the run report is evaluated against these criteria, so instead of reading each report line by line to decide whether the run went well, you get an evaluation you can check at a glance and dig into only when something misses.

Write criteria the same way you wrote instructions: testable over vibe-based. "The summary is useful" cannot be evaluated. "The summary includes a count of urgent emails and a one-line reason for each urgent label" can.

Step 7: Run it, watch it, and read the whole report

Trigger the first run manually and actually watch it. Skopx shows a live step timeline as the run proceeds: humanized labels for each action the agent takes, expandable to the raw results underneath, plus a running duration and token count. If the agent heads somewhere you do not like, you can stop the run mid-flight; stopping always wins.

When the run completes, it ends in a markdown report. Read the entire first report, including expanding the raw results behind a few steps to see what the agent actually got back from each tool. You are auditing three things:

1. Interpretation. Did the agent understand the instructions the way you meant them? The gap between what you wrote and what it did is your revision list.
2. Judgment. Where the instructions left room for decisions, were the decisions ones you would have made? If not, the fix is usually a new decision rule in the instructions.
3. Efficiency. Did it take a sensible path, or did it wander? Wandering usually means the instructions under-specified the method, or the agent lacks a tool it needed and improvised around the gap.

The first run is almost never perfect, and that is the design, not a failure of it. The loop is: run, read, revise instructions, run again. Because instructions are versioned, you can revise freely, and because run history is append-only, you keep a complete record of how behavior changed as the instructions did. Most agents converge to trustworthy within a handful of iterations.

Step 8: Promote to autonomy, one notch at a time

Autonomy is not a switch you flip at creation. It is a series of small promotions, each justified by observed behavior:

1. Manual trigger, everything asks first. You start runs and approve every write. This is where every agent begins.
2. Manual trigger, routine writes automatic. The writes you have approved identically ten times stop needing you.
3. Scheduled or webhook trigger, sensitive writes still ask. The agent runs without you starting it, but the actions that could embarrass you still park for approval.
4. Full grants within budgets. For agents whose failure modes you now understand and whose worst case the budgets bound.

Many useful agents should stop at level 3 permanently, and some at level 2. An agent that sends invoices or posts publicly may deserve an approval gate forever, and the honest framing is that this is fine: an agent that does 95 percent of a job and asks about the last 5 percent is still doing 95 percent of the job.

Throughout all of this, the pause control is your kill switch. Pausing an agent kills its queued runs, immediately, regardless of trigger. Knowing the off switch works, and works instantly, is precisely what makes graduated autonomy a reasonable bet rather than a leap of faith.

Where people go wrong

Some failure patterns show up so often they are worth naming in advance:

The mega-agent. One agent instructed to triage support, watch competitors, and update the CRM. Each job pollutes the others' instructions, and a failure in one blocks all three. Build one agent per job; the workspace rail exists so a collection stays manageable.

Instructions frozen after run one. The revision loop is the mechanism by which agents get good. Treating the first draft of instructions as final means shipping the agent at its worst.

Grants sized to ambition rather than need. Granting five toolkits because the agent "might need them" widens the blast radius for zero benefit. Grant what the job requires; add more when a run report shows the agent genuinely blocked.

Skipping success criteria. Without them, supervision means reading every report forever, which means supervision quietly stops happening.

Trusting a webhook payload. If external input can steer an agent's actions, anyone who can send the input can steer the agent. Payloads are data to examine, never instructions to follow.

FAQ

How long does it take to create an AI agent this way?

The initial description takes a few minutes: you type a paragraph, the chat assembles the agent, and you review the instructions, trigger, grants, and budgets it proposes. Reaching an agent you trust takes longer, typically a handful of supervised runs with instruction revisions between them, spread over however many days the trigger cadence implies. The honest budget is minutes to create, a week or so of light supervision to trust.

Do I need to know how to code?

No. On Skopx the entire path in this guide happens in chat and in plain language: instructions are prose, triggers are phrases like "Every Monday at 9:00 UTC," and grants and budgets are settings you review rather than code you write. The skill that matters is the briefing skill: describing a job precisely enough that someone who is not you could execute it. Technical background helps only insofar as technical people are practiced at writing unambiguous specifications.

What does it cost to run an agent?

On Skopx you either bring your own API key for any of 8 supported model providers, with zero markup on usage, or use the Team plan at $16 per seat with included tokens. Actual consumption depends entirely on the agent: how often it runs, how many steps a run takes, and how much data it reads. The budget caps in step 5 are how you bound the spend, and the per-run token counts in run reports are how you learn what a job really costs you. Note that agents with memory typically get cheaper after their first run, since delta runs process only what changed.

Which model should I pick for my agent?

Skopx lets you choose per agent among Claude, GPT, Gemini, Kimi, and others. A reasonable default: use a strong reasoning model while you are iterating on instructions, because it surfaces ambiguities in your brief that a weaker model would silently guess through. Once the agent is stable and the job is well-specified, you can test a lighter model against your success criteria and downgrade if it still passes. The per-agent choice means a hard research agent and a simple labeling agent do not have to share a model.

Can I change an agent after it is created?

Everything is editable. Instructions are versioned, so revisions never destroy history. Triggers can move between manual, schedule, and webhook. Grants can be tightened or promoted per toolkit. Budgets can be resized as run reports teach you real consumption. The only thing you cannot edit is the past: run history is append-only, which is what makes it a trustworthy record of how the agent behaved at every stage of its evolution.

What happens if the agent does something wrong?

It depends on the tier of the action. Write-shaped actions under an approval grant cannot execute at all until you approve the exact parked call, so "wrong" stops at a pending approval you reject. For actions the agent runs automatically, budgets bound how far a bad run can go, you can stop any run mid-flight, and pausing the agent kills everything queued. Afterward, the step timeline shows exactly what happened, which is the raw material for the instruction revision that prevents the repeat.

Start smaller than feels impressive

The best first agent is a job you already do, that happens mostly inside one or two tools, where the cost of an imperfect run is minutes of your review time. Inbox triage, a morning digest, a weekly data-quality sweep. Describe it in a paragraph, keep the grants conservative, watch the first run, and revise.

The impressive agents, the ones that run on schedules you have forgotten about and surface only exceptions, are not built impressive. They are built small and promoted, one earned notch of autonomy at a time. The Skopx agents overview shows what the destination looks like; the paragraph you write today is how you start walking there.