Turn a working prompt
into a reusable agent.

Start with one task you already understand. Keep the prompt, an example input, and the result you wanted. Mark the rules that must hold every time. You can paste that material into Method, or write a local .method file with the SDK.

1. Separate inputs from instructions.

Consider a small task: “Save this text without changing it.” The text changes between runs. The requirement to preserve it does not. Declare the text as an input, and put the stable instruction in the step.

For a larger task, inputs might include a date range, a customer name, or a list of approved sources. Keep account credentials in your local tool setup, outside the method and its input files.

2. Give each step a clear result.

A step should produce something another step or a person can inspect. For the file example, that result is a saved file. In a research method, separate source collection, evidence checks, and writing the brief. This makes it easier to identify the part that failed.

format: method/2
name: Save and check a text file
goal: Preserve the exact supplied text in a saved file.
inputs:
  text:
    type: text
    description: Exact text to save, including whitespace.
steps:
  save:
    in:
      text: inputs.text
    do: Write text to the assigned file location without changing it.
    out:
      file:
        type: file
        description: The file containing the complete supplied text.
        format: text
    check: Read file and confirm every character matches text.
result: file

Download the complete file example. The quickstart shows how to validate and run it.

3. Make the check specific.

“Make sure it looks good” leaves the result open to interpretation. “Read the saved file and compare every character with the supplied text” gives the check a clear input and condition. Method also supports exact equality, count, presence, and file checks where those fit the task.

Model checks can still be wrong. Keep their evidence and inspect it. Validation checks the method structure; it does not prove that an agent will perform the task correctly.

4. Run with a small input.

Use a local test folder and data you can inspect. Review the result, returned files, and checks in the run directory. Confirm both the requested output and any changes the method made.

5. Improve the rule that caused the failure.

If a step fails, read its recorded inputs and evidence before changing instructions. Keep stable step names when you edit. Validate the new file and save a version with a short reason. Keep the earlier run so that you can compare the result.

When a run made an external change, inspect that change before retrying. A timeout does not prove that a remote write failed. The SDK cannot guarantee exactly-once delivery to another service.

What to build next

Use the same approach for a research brief. Give it a fixed scope and approved sources, then require evidence for each finding. For more complex business rules, read why long prompts become incident logs.