Choose an agent by the job you need done

01 / Field note

Describe the result before choosing a tool

An agent name is not a specification. “Productivity assistant” could mean a list of suggested priorities, a calendar integration, or a system that changes appointments. Start with one sentence describing the artifact you want and the authority you are willing to grant.

For example: “From these redacted meeting notes, produce a table of agreed actions, owners and deadlines, with a source excerpt for every row. Do not email anyone.” This gives you something concrete to compare. A resource that only writes a meeting summary may be useful, but it does not yet meet that brief.

Write down what a successful result would let you do next. If you cannot inspect the proposed output or describe an unacceptable error, narrow the task before selecting a package.

02 / Field note

Read the resource as a working agreement

Compare the required input, promised output and limits together. A source-grounded research resource needs actual sources. A calendar checker needs dated intervals and time-zone context. Missing requirements cannot be repaired by a polished description or a confident answer.

Look for explicit platform setup, examples, a version and a creator attribution. Check whether examples are illustrative or observed test runs. Testing on one host or one case is useful evidence, but it does not establish universal reliability.

Also check the reuse terms. Permission to use a package, change it and redistribute it are separate questions. A publicly readable page does not automatically give you every reuse right. Follow the stated package terms and ask the rights holder if they are unclear.

03 / Field note

Distinguish instructions from automation

Interactive instructions describe how an assistant should work in a conversation you start. They do not, by themselves, connect an account, schedule a job or send a message. A workflow artifact may require a particular runtime, integrations, credentials and separate permissions.

If your need is “summarize tomorrow’s messages every morning,” a package that summarizes a pasted email batch covers only part of that job. Check separately for mailbox access, filtering, scheduling, delivery and failure handling. Do not treat these missing steps as implied features.

Choose the least authority that accomplishes the task. A reviewable draft is often enough for a first run. Connecting a system that can change records adds consequences that must be considered independently of writing quality.

04 / Field note

Compare a small, representative example

Use a short synthetic or appropriately redacted input that resembles your real work. Decide the expected result before reading the model response. For meeting notes, include one confirmed action, one proposal without agreement and one missing deadline. A useful result must distinguish all three.

Compare two candidates against the same input. Record whether each preserves facts, identifies missing information and stays within its authority. Check quoted evidence against the input rather than trusting a citation-shaped label.

If neither candidate passes, adjust the task or look for a better fit. Do not average away an unauthorized action or an invented fact because the rest of the answer sounds good.

05 / Field note

Keep a short selection record

Capture the package and version, chosen platform, input requirements, example used, observed problems and decision. This makes a later update reviewable and helps you notice when a different model or integration changes the behavior.

Your first decision can be “use for drafts only” or “try again with clearer inputs.” Choosing a resource is a bounded experiment, not a promise to automate the whole process.