Reuse an agent pattern when its intended job, information, actions, and review point match your workflow. Configure it when your differences fit supported settings. Build custom only when a necessary integration, control, or operating step remains unmet and your team can maintain it.
Fictional example: Maple Freight wants to review supplier onboarding packets. A pattern in its approved Agent Library reads a packet, compares it with an intake checklist, flags missing evidence, and drafts a follow-up request. Maple’s workflow also needs to compare the packet with its current vendor record. The team cannot assume the pattern has that connection or can access it; it must verify the listing and allowed configuration first.
Choose by workflow fit, then verify sources and actions for the selected option.
Compare the three choices
Scroll horizontally to see all columns.
| Choice | Use it when | Check before committing |
|---|---|---|
| Reuse | The pattern already covers the task and its expected output. | Does its source scope, authority, review point, and failure path fit your process? |
| Configure | The task is the same, but approved sources, wording, or bounded options need to change. | Are these differences supported settings, and can you verify what each setting changes? |
| Build custom | A required system connection, control, or operating step is outside the pattern’s supported scope. | Can the team test, secure, monitor, and maintain the added workflow? |
Separate discovery, approval, and build effort
A reusable agent library helps you find a starting point. Public discovery and internal approval are different steps: anyone can submit an agent to an organization or team library, and the relevant managers vet and approve what is included. Approved organization agents are available throughout the organization; approved team agents are limited to team members. Verify access to business data separately from that availability.
Before comparing development effort, write the one requirement that could force a custom build. For Maple, it is authorized comparison with the current vendor record. A wording preference is usually a configuration question; a necessary unsupported connection or review state can change the architecture. Compare setup effort, testing, maintenance, and exception handling over the same operating period. Neither a library listing nor custom code removes those responsibilities.
Test Maple’s request against the pattern
Maple’s request is: “Compare the supplier packet with our approved intake checklist and current vendor record. List missing evidence and draft a request for review. Do not approve the supplier or send a message.” The packet and checklist match the pattern’s stated job. The current vendor record is an additional source, so Maple first checks whether the pattern can use that authorized source without changing the required approval boundary.
If the source can be added through a supported setting, the team can configure and test the same pattern. If the library pattern cannot access the record but another approved read-only integration can provide it, the team may compare that integration with its requirements before building. If the required access, review step, or audit trail is unavailable, the agent does not fit yet. Custom development is justified only if that difference is necessary for the job and an owner can operate it.
The decision note could read:
Decision: Test the existing supplier-intake pattern first. Its packet review, missing-evidence list, and draft request match the task. The vendor-record comparison is an unresolved requirement. Proceed only if an authorized read-only source can be configured and tested. Keep approval and sending with a procurement reviewer.
The open question is whether the pattern can read Maple’s vendor record with the required permissions. Resolve that before committing to custom development.
Record the reuse, configure, or build decision
Write the decision down before the pilot starts. The record keeps everyone working from the same answer, and it shows the next owner why the choice was made. The agent can draft most of it from the listing, your job description, and the sources you name. The team confirms the job, the decisions people keep, the owner, and the final choice.
Reuse, configure, or build decision record (blank)
- Job and what a good result looks like: ___
- Candidate agent and date checked: ___
- Information it needs, and who owns each source: ___
- Connections the agent does not have yet: ___
- What the agent may do, and what a person decides: ___
- Test cases (ordinary, missing information, conflicting information, source unavailable): ___
- Owner for problems, changes, costs, and retirement: ___
- Decision (reuse, configure, or build): ___
- What must be confirmed before going ahead: ___
Maple's completed record looks like this:
Reuse, configure, or build decision record: Maple Freight (fictional)
- Job and what a good result looks like: Review each supplier packet, list missing evidence, and draft a request for the supplier. The agent does not approve suppliers or send messages.
- Candidate agent and date checked: The existing supplier-intake agent, checked against its current listing.
- Information it needs: The submitted packet and the approved intake checklist, both owned by procurement. Vendor-record access is not settled yet.
- Connections the agent does not have yet: Read-only access to the current vendor record.
- What the agent may do, and what a person decides: The agent compares, lists, and drafts. A procurement reviewer approves suppliers and sends every request.
- Test cases: A complete packet, a missing certificate, contradictory dates, and a vendor record that cannot be reached.
- Owner: The procurement process owner, who names the day-to-day operator before the pilot.
- Decision: Configure, as long as the vendor record can be added without giving the agent any new actions. Otherwise, pause and price the custom work.
- What must be confirmed before going ahead: That a supported, read-only connection to the vendor record exists and passes the four tests.
The last line matters as much as the decision itself. When you compare options, compare them over the same workload and the same period. Include testing, repeat attempts, exceptions, and upkeep, not only setup.
Verify the operating fit, not just the demonstration
For any option, compare the real request, accepted output, approved sources, permitted actions, human decision, exception path, and owner. Inspect how incomplete data and conflicting records are handled. Try a representative test set, including an out-of-scope request and an unavailable source. A polished demonstration does not show whether the agent fits your own information or permissions.
Estimate ongoing work too: source updates, connection credentials, reviewer time, version changes, error handling, and retirement. Reuse can reduce repeated design work, but it does not remove the need to validate the workflow. Custom development adds choices the team must document and maintain.
Browse the current Agent Library, then write a focused job brief and evaluate the adapted workflow. For AgentShelf-specific configuration concepts, see the agent harness overview.