AI Tools Field Guide

Open edition · no CAC needed

Advanced — Build with it

Agents and automation

Lesson 3 of 14≈6 min

An agent is a language model in a loop with tools. Build one worth sharing, know what these builders will not automate today, and put a test around it before anyone else depends on it.

  1. One turn of the loop, repeated until a stopping test or a budget ends it
    1. 1Read the contextThe request, the files, every result so far
    2. 2DecideAnswer now, or call a tool?
    3. 3Call a toolSearch, read a file, run a command
    4. 4Read the resultIt joins the context, and the loop goes round again

When it decides it can answer, the loop ends and you get the reply.

What an agent is

An agent is a language model in a loop with tools. Each pass through the loop it reads the context, decides whether to answer or to call a tool, calls one, reads the result, and goes round again until a stop condition ends it. The intelligence is the model. The ability to act is the tool set. The persistence is whatever files or project it can write to. None of those parts is new; the loop is what makes it an agent.

Part What it is Who set it
The model The next-token predictor The vendor
The instructions The job, the procedure, the output format: a skill file by another name You
The tools Functions it may call: search, files, connectors, code Whoever granted them
The loop Read, decide, act, read the result, repeat The harness
The stop condition "Done", a step budget, an error, or a test that passes You, or nobody, which is the problem
Persistence Files, a project, memory You

Inside a builder

Screenshot to come

gemini.google.com > Gems > New gem (or the Gemini Enterprise agent builder start screen): the "what do you want your agent to do" prompt box and starter cards; same crop, no banner.

A Gemini Gem builder: the job in plain language on the left, the agent's behavior tested on the right.

A Gem builder in Gemini builds an agent from a description in ordinary language: what the agent is for, what it should ask for, what it should produce. Under the form it is assembling the table above: your description becomes the instructions, the model is Gemini, the sources you attach become what it can read, and a chat is the loop. The agent stays a draft until you publish it, and a published agent can be shared to named users or to your whole organization (Google help).

Custom GPTs in ChatGPT and playbooks in Grok are the same pattern under other names: standing instructions plus sources plus a model, packaged so someone else can run it. What you learn building one transfers to the others.

What it will not do yet

Builders like these have limits worth knowing before you design around them. Check the product; some may have moved since.

Common limit What it means for your design
No automated delivery Nothing runs at 0600 by itself. "Automation" means a person opens the agent and runs it, unless the product offers a scheduling feature specifically.
Sources are uploaded files or public sources It cannot watch a shared drive or a mailbox. Someone feeds it.
Sharing by adding users one at a time Plan the roster; a shareable link is not always available.
No persistent memory across chats, on most builders Each run starts clean. State lives in the files you give it.
Weak table and font formatting; no spreadsheet export Ask for plain structured text and paste it into the template yourself.
Image generation unreliable Draft the words; make the picture elsewhere.

So an agent built this way is a reusable, shareable procedure with a model attached, run by a person. That is still worth having: the person no longer re-explains the job, and every run follows the same procedure. If a job must run on a schedule or pull from a system of record, that is the API and your data or AI shop.

Building one that holds up

  1. Write the job in one sentence
  2. Attach the source documents
  3. Paste one approved output as the example
  4. Run five known inputs
  5. Publish to three people
  6. Review the transcripts weekly

The example and the five known inputs are where most of the quality comes from.

The one sentence is the description that decides when the agent fits. The approved output is the format teacher. The five known inputs are inputs whose right answer you already have, so you can see whether the agent got there; keep them, because you will rerun them every time you change the instructions. Publishing to three people first gives you three readers of the transcripts before the whole command finds the gaps.

Reading a transcript

An agent's transcript shows every layer, and it is the only place the truth about a run lives. Roughly, top to bottom:

Line in the transcript Who wrote it
System prompt The vendor and your organization
Tool definitions, one per connector and skill The harness
"Draft the read-ahead from these three documents." The person running it
Tool call: read the first file The model, as a structured request
Tool result: the file's text, possibly cut The harness
The draft The model
"[Earlier turns summarized]" The harness, on compaction

If there is no tool call, there was no search and no file read. If a tool result is cut, the model saw the head and the tail of the file and nothing between. If a summary line appears, the details above it are gone. Those three checks take a minute and catch most of what goes wrong.

Evaluating an agent

An agent that "seems fine" has not been evaluated. Evaluation is the five known inputs made permanent:

What to do with this

Take the skill file you wrote on the skills page and build it into an agent with five known inputs and three reviewers. Then read what happens when an agent hands work to another agent: Subagents and sessions.

Vendor facts checked ; re-verify before relying on them.