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.
A reusable pattern can share a workflow shape while each team supplies its own boundaries.
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? |
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 state, or audit path is unavailable, the fit has not been established. 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.
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 cannot establish that the pattern fits your own evidence 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.