How to build a natural-language agent

I have been building products for a long time, and I have watched a lot of "no-code" and "AI agent" promises come and go. So I have learned some behavior to be skeptical by nature and to be especially skeptical of frankly the toys being built in the industry that are flashy but that don’t actually really solve a real problem for a team. The thing that changed my mind was not a framework or a clever prompt. It was realizing that the best way to build an agent looks almost exactly like onboarding a good new hire.

You do the work with them once. You write down how you do it. Then you get out of the way.

That is the whole arc of this post. We are going to build a real natural-language agent, step by step, using a task every engineering team has: logging bugs. We will start by doing it manually, then capture the process as a skill, and then let it run on its own with Proactive Agent Mode. No new codebase. No pile of glue scripts. Just plain language and a few good habits.

Let me show you.

What is a natural language agent?

The simplest way I can describe it: a natural-language agent is an AI-enabled coworker you instruct in plain natural language instead of in code. You tell it what "good" looks like, give it access to the tools you already use (Slack, Linear, GitHub, your database), and it does the work and reports back.

In Adapt, an agent has three key parts:

• Integrations. The tools and data it can reach (Slack, Linear, GitHub, BigQuery, and so on).
• Skills. Reusable, versioned instructions that capture how your team does a specific job.
• A trigger. When the agent should act: on mention, on its own judgment, or on every message.
  • Typically this is a Slack channel which encapsulates collaborative workflows and why Adapt as an integrated coworker meets you where you work

The magic is not in any one of these. It is all of them working in tandem which is where real work gets done not AI theatrics that don’t lead to a measurable productivity improvement. You start manual, you understand the discrete steps that drive your own understanding and then you encapsulate with a skill and an automation (or in modern parlance: an agent that does work).

The running example: logging bugs

Every team has a bugs channel, and every bugs channel has the same problem. Someone drops a screenshot and the word "broken." Someone else pastes a stack trace at midnight. A third person writes "is this a known issue?" Half of these never make it into the tracker. The other half get logged three different ways.

This is a perfect first agent because the work is real, repetitive, and easy to judge. We know a good outcome when we see one: a clean, deduplicated issue in Linear with the right team, the right priority, and enough context for an engineer to actually start.

Let us build it.

Step 1: Do it manually, with the agent in the loop

Before you automate anything, do the job with the agent watching over your shoulder. This is the equivalent of pairing with a new hire on day one.

In practice that looks like a normal chat:

"A user reported that the export button does nothing on Safari. Can you check if we already have an issue for this, and if not, file one in Linear on the ENG team with the details and a repro?"

Adapt goes and does it. It searches Linear for duplicates, reads the thread for context, drafts a clean issue with a title, a Problem section, and repro steps, and posts back a link. You review it. Maybe you correct the priority, or tell it to attach the screenshot, or note that this one belongs on the APP team instead of ENG.

Two things are happening here that matter more than the bug itself:

• You are discovering the real process. The messy edge cases (missing repro steps, duplicates, which team owns what) surface now, while a human is still driving.
• You are teaching by correction. Every "actually, do it this way" is a rule you will want to keep.

Do not skip this step. The manual pass is where the knowledge comes from. An agent built without it is just a guess.

Step 2: Encapsulate the process as a skill

If you can't describe what you are doing as a process, you don't know what you're doing.

Once you have logged a handful of bugs and the corrections have slowed down, you have a process worth writing down. In Adapt, that written-down process is a skill.

A skill is exactly what it sounds like: a reusable capability, written in plain language, that the agent loads when it recognizes the task. It is not code. It reads like the runbook you would hand a new teammate. A bug-logging skill might say:

• When someone reports a bug, first search Linear for an existing issue before creating a new one.
• If it is a duplicate, add the new details as a comment and link the report instead of filing again.
• If it is new, create an issue with our standard sections: Problem, Steps to Reproduce, Expected vs Actual, and Context. Put code and file names in backticks.
• Route it to the right team: app-facing bugs to APP, backend to ENG. Default priority is Medium. Anything about data loss or auth is High.
• Attach any screenshots or recordings from the thread.
• Reply in the thread with the issue link and a one-line summary.

Notice what just happened. The tribal knowledge that lived in your head, and in the corrections you made in Step 1, is now a durable, shared asset. Anyone on the team can invoke it and get the same quality. When your process changes, you edit the skill, not forty different prompts.

This is the highest-leverage move in the whole post. A good skill turns "the way one person does it on a good day" into "the way it is always done."

One cool power move is adding Adapt to a channel (like #bugs, #features, #ui-issues, etc.) and then asking it to read all the messages, observe the human activity, and encapsulate the workflow with a skill like so:

@Adapt read all the messages in this channel and let’s build a skill together that automates the manual process with a skill. Let’s review it together before saving it.

Step 3: Automate it end to end with Proactive Agent Mode

Most teams get here in their AI-native journey, they have a skill and then there’s a hope that the skill gets ratified and internalized in team workflows and used. But a hope isn’t a strategy, it needs to be used and used consistently which is where Adapt as an integrated coworker is where it stops feeling like a tool and starts feeling like a teammate.

So far, the agent only acts when you ask. That is the default, and it is the right default: you do not want a bot barging into every conversation. But now that the skill exists and you trust it, you can let the agent watch the bugs channel and act on its own.

You turn this on the same way you do everything else in Adapt: by asking. In the bugs channel, you just say:

@Adapt From now on, whenever someone reports a bug in here, triage it and file it using our bug-logging skill

That sets the channel to a proactive response mode where you’re giving the Adapt agent more flexibility to autonomously do work and just wait to be triggered. Adapt now reads new messages in the channel, decides whether each one is actually a bug report (a screenshot, an error, a "this is broken," even an "is this a known issue?"), and if it is, it runs the skill: dedupes, files the Linear issue, attaches the screenshot, and replies in the thread with the link. If a message is just banter, it stays quiet.

Proactive Agent Mode comes in three sensitivities, and the progression matches how much you trust the agent:

• Mention only. Acts when you tag it. The safe default.
• Smart. Uses its judgment to decide when a message deserves a response. This is the sweet spot for a bugs channel.
• Always respond. Reacts to everything. Useful for narrow, high-signal channels.

The bar for a proactive agent is high, and it should be: it has to add value every single time it chooses to speak, or it becomes noise that humans are getting increasingly tuned to ignore. That is exactly why we built it in this order. By the time you flip it on, the skill has already been pressure-tested by hand.

This is not hypothetical. We run this on ourselves. Adapt triages the bugs in our own bugs channel today, and the pattern re-enforced by our customers like Wander, who wanted Adapt watching their bugs channel instead of a bot they had to build and maintain themselves.

You can view our skill and try it yourself with our “Bug Triage Workflow” example. Not a toy, not a theoretical example, a real workflow that we use every single day to make Adapt better for our customers and users like yourself.

The pattern, not the example

We used bugs, but the shape is the point, and it generalizes to almost any recurring workflow:

• Do it manually with the agent in the loop, so the real process reveals itself.
• Encapsulate it as a skill, so the knowledge becomes durable and shared.
• Automate it with Proactive Agent Mode, so it runs without you.

Swap "logging bugs" for triaging support tickets, drafting the weekly metrics report, qualifying inbound leads, or reviewing pull requests. The three steps do not change.

Why this order matters

Most agent projects fail because they start at Step 3. Someone tries to automate a process they have never actually written down, the agent does something slightly wrong at scale, and everyone concludes that agents "are not ready."

The best part is that none of this required a new engineering project. You taught a capable coworker the way you would teach a person: you showed it the work, you wrote down how you do it, and then you let it run. That is how you build a natural-language agent. And honestly, once you have built one, you start seeing them everywhere.

It remains a great time to build, and an even better time to build with Adapt. Have fun out there!