How do you keep FDE work from becoming bespoke technical debt?

A useful customer implementation can become difficult to maintain when its assumptions live only in the head of the person who built it.

The aim is to preserve what makes the solution useful while making future changes understandable. This guide proposes a practical review for forward deployed work; it does not describe a measured client engagement.

Separate the policy from the plumbing

In an illustrative morning-brief workflow, reading a calendar is an integration concern. Deciding which meetings need preparation is a business policy. Keeping those decisions separate makes it possible to change the policy without rebuilding the connector.

Record the source, owner, and reason for each customer-specific rule. Configuration is useful when a rule genuinely varies. A configuration file full of unexplained exceptions simply moves the maintenance problem.

Start with a small architecture

Anthropic's guidance on effective agents recommends starting with simple approaches and adding complexity when it improves the task. It distinguishes predefined workflows from agents that choose their own steps.

Apply that distinction to each part of the implementation. Use an explicit rule for a known approval boundary. Use model judgment where inputs require interpretation. Document why an agent is needed and what evidence would justify a simpler replacement.

Give each integration a contract

For every handoff, write down the input, expected output, permissions, and response to failure. What happens when a source is missing? Can the operation be repeated? How does the next stage know that an output is incomplete?

Keep authentication and permission enforcement in the connected systems. A prompt describing a restriction is not a substitute for restricting the credential or action itself.

Turn corrections into regression checks

Save representative inputs, the expected outcomes, and the reason each example matters. Include missing data and ambiguous requests alongside ordinary cases. Re-run those checks when a prompt, model, connector, or business rule changes.

Anthropic's evaluation guide describes combining code-based, model-based, and human evaluation. For an implementation, choose checks that can detect the failure you care about. A second model agreeing with a draft does not establish that its source facts are correct.

Reuse the part that has earned reuse

Two customers may need a similar report while using different access rules and definitions of urgency. Reuse the connector or rendering component when its contract is stable. Keep customer policy separate. Avoid a shared abstraction that forces every future customer to inherit the first customer's assumptions.

Before extracting a reusable component, identify its users, supported inputs, tests, and maintenance owner. Shared code without ownership can spread the cost of a mistake across projects.

Review the handover as a product

Ask someone who did not build the workflow to run it, inspect a failure, and change a simple rule using the documentation. Record where they need help. That exercise exposes dependencies a successful demo can hide.

• Can another engineer deploy the documented version?
• Can an operator see what failed and pause new work?
• Can the team trace each exception to its reason?
• Can a change be checked against previous failures?
• Is ownership of shared and customer-specific code clear?

The practical goal is a system the next person can understand and improve. Treat that as part of delivery, not a cleanup task for an unspecified future project.

Sources and editorial notes

• Building effective agents — architectural simplicity and the workflow/agent distinction.
• Demystifying evals for AI agents — evaluation methods.

The implementation examples and review checklist are editorial synthesis. No performance or cost savings are claimed.