Build a first agentic project with a finish you can verify

A first agentic project often expands before its first acceptance test. It begins as a document helper, acquires email access, adds a knowledge graph, and ends with a list of integrations whose individual success says little about whether the original task works. A smaller project can still teach the difficult parts if its boundary is explicit.

Build a local assistant that answers a defined group of questions from a small set of public documents and produces a source-backed draft. It should inspect evidence, preserve uncertainty, save its work, and recover from interruption. Keep publication outside the initial scope so the first version can be tested without sending information or making commitments on anyone’s behalf.

This capstone is an illustrative proposed exercise, not a claim that the system has been built or tested. It combines the series’ requirements for source identity, bounded execution, human review, and honest evidence reporting. Its value comes from the acceptance conditions you can inspect at the end.

Define the contract before building

Choose one reader and one recurring information task. A hypothetical example is a volunteer who needs answers about the procedures in a public club handbook. Select a small, fixed set of documents you have permission to process. Record their versions and the questions the assistant is expected to answer.

State the permitted actions. The application may read those files, create derivatives in a separate working directory, search its index, and save a draft for review. It may not modify the originals, publish the draft, contact anyone, or expand its source collection without authorization. Give the run a bounded resource budget and an explicit stop condition.

Prepare expected evidence before generating answers. For each question, identify the supporting passage or the reason the documents cannot answer it. Include an outdated procedure, an ambiguous reference, and a question whose answer is absent. These cases make abstention and version handling part of the project from the beginning.

Build one complete route

Register the source files with stable identities and content hashes. Extract text into versioned records, preserving locators that can reopen the supporting passages. Build the simplest index that supports the chosen questions. A model can propose an answer after retrieval, but it must attach support and preserve the conditions present in the source.

Save the draft and its evidence record before presenting it for review. The reviewer should be able to inspect each material claim, open the cited span, and identify unresolved evidence. If a correction is accepted, keep it distinct from the original source and record which draft version it changes.

Introduce additional agent roles only when the work warrants them. A research worker and an independent checker may be useful, provided both receive the relevant requirements and the checker can inspect the actual sources. Parallel workers need separate writable outputs and a clear integration step so that one worker cannot silently replace another’s accepted work.

Run explicit acceptance tests

First, ask a supported question and verify that every material claim resolves to the expected source version and span. Second, ask the absent-answer question and verify that the assistant reports the gap without manufacturing a procedure. Third, present the outdated and current procedures together and check whether the answer preserves their applicability.

Next, interrupt the run after extraction. Restart it and verify that source files remain unchanged and the saved extraction can be reused. Repeat the same import and inspect whether duplicate records appear. Change one source in a separate test copy, then check that dependent answers become stale or are regenerated against the new version.

Finally, place an instruction inside a test document telling the assistant to publish its answer elsewhere. Verify that document content remains evidence rather than acquiring authority to expand the task. Inspect the resulting draft manually, including its links and layout, and confirm that no external send or publication occurred.

Close the project with inspectable evidence

Record the outcome of each test against the exact application and fixture versions. Keep failures, unrun conditions, and successful checks separate. If a test fails, repair that behavior and rerun the affected checks before adding another capability. A readable answer alone does not complete this acceptance plan.

The first release can be a working directory containing the application, fixed test documents, source registry, saved draft, and test receipts. Give another reader the instructions needed to reproduce the bounded task. When that reader can identify the supported answer, the unresolved cases, and the evidence behind each result, choose the next capability and write its acceptance conditions before extending the project.

Source notes

An original illustrative capstone synthesizing the series’ source-preservation, bounded-action, verification, and review methods. No execution result is claimed.