Provider research
Not every capability should be built in-house. Authentication, transactional email and real-time media are usually better bought than built. When the agent identifies one of these, it researches the current options and asks you to choose.
When research happens
Section titled “When research happens”Research is triggered during architecture, when the design needs a capability that is not a good fit for a generated service. Typical cases:
| Capability | Usually external because |
|---|---|
| Authentication | Identity is a security surface, not a differentiator |
| Transactional email | Deliverability is an operational specialty |
| Voice and video | Media transport needs stateful sessions and UDP |
| Payments | Regulatory and compliance burden |
The agent does not decide for you. It researches, recommends, and asks.
What the research produces
Section titled “What the research produces”For each capability, the agent searches current documentation and pricing, then presents a comparison with a recommendation and its reasoning.
The comparison includes free-tier limits, because those often decide the choice for a first version.
Choosing
Section titled “Choosing”You pick from the researched options, or write your own answer.
Your choice becomes a pinned decision in the engineering guide, so later runs follow it rather than re-litigating it.
What gets recorded
Section titled “What gets recorded”The choice is written into the specification, not just used once:
- The provider appears in the system design’s external dependencies table
- The owning service’s engineering guide records the SDK and version
- The architecture decision record explains why
That means a later run — or a human reading the repo — sees the same reasoning you did.