adr: FullEnrich connector

[rsindall]

Summary

• Short human ADR asking for a first-class FullEnrich connector (person / company enrichment).
• Same shape as other connector ADRs: Admin config, spend limits, MCP or native tools.

Test plan

• Maintainer review of adrs/fullenrich-connector.txt only (no code)

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[rajpratham1]

This proposes a useful product enhancement—a first-class FullEnrich connector—but it is not yet an Architecture Decision Record. It reads as a feature request and lacks the architectural detail needed to evaluate or document a design decision.

What is good
Identifies a legitimate use case:
Commercial agents frequently perform person and company enrichment.
Today this requires custom sandbox tooling or direct HTTP/API integrations.
Defines a reasonable MVP:
Admin-configured API key.
Person lookup.
Company lookup.
Optional bulk enrichment.
Writes deferred until later.
Explicitly keeps write operations gated, which is a sensible design principle.
Leaves implementation flexibility by suggesting either:
a native connector,
an MCP recipe,
or both.
Blocking issues

1. This is a product request rather than an ADR

An ADR should answer:

What decision is being made?
Why this approach?
Why not the alternatives?
What are the consequences?

This proposal only describes desired functionality.

2. Connector architecture is unspecified

The document suggests:

first-class HTTP/API connector

or

first-class MCP connector recipe

These represent different architectures with different trade-offs, but the proposal does not recommend one or explain why.

For example:

Should QM own the API integration directly?
Should FullEnrich simply be packaged as an MCP connector?
When would one approach be preferred over the other?
3. Authentication and secret management are not discussed

The proposal says:

Admin can register a FullEnrich API key

but doesn't explain:

where the key is stored,
how it's rotated,
whether multiple credentials are supported,
whether different scopes can use different credentials,
how usage auditing works.

These are important considerations for an admin-managed connector.

4. Spend controls need more detail

The proposal mentions:

clear spend limits

without defining:

per request?
per user?
per organization?
monthly budget?
hard limit vs warning?

Since spend control is one of the stated motivations, the expected behavior should be described.

5. API surface is vague

The proposal mentions:

person lookup
company lookup
bulk enrich

but doesn't define whether QM exposes:

generic enrichment primitives,
provider-specific tools,
or simply proxies the FullEnrich API.

This affects long-term extensibility.