Connector Overview

Connectors give Jardine access to runtime account facts that documentation alone cannot provide. This is what enables answers to questions like “what plan is this user on?” or “what is the current billing state?” without forcing agents to manually look up data on every conversation.

A connector is not a general-purpose data pipe. It is an operational context layer for support decisions.

What Connectors Solve

Knowledge Library is excellent for policy and product guidance. But account-specific support needs live data.

Without connectors, account-sensitive requests often need human handoff by default. With connectors, Jardine can retrieve scoped facts at runtime and handle more of those flows safely.

In practical terms, connectors reduce repetitive lookup work and shorten time-to-resolution, especially for billing, subscription, and account state questions.

Providers and Modes in the Current UI

The connector interface currently supports Postgres, MongoDB, Supabase mode, and Stripe.

You can configure connectors in automatic or manual modes.

Automatic mode is useful when you want simpler operation with schema-awareness and fewer manual components. Manual mode is useful when you need explicit template control over exactly what operations can run.

As with routing, start simple unless there is a clear policy reason to increase complexity.

Templates and Controlled Data Access

For manual control flows, template libraries are a central feature. Templates define named operations (for SQL, Mongo operations, or Stripe operations) that can be tested and reused.

This is an important safety pattern. Named templates create predictable access boundaries, make behavior easier to audit, and reduce accidental query sprawl.

In the connector UI, you can add, edit, delete, and test templates with explicit parameters. Test results help verify that both query logic and output shape are correct before using those templates in real support contexts.

Teams that rely on template testing before rollout usually see fewer production incidents than teams that skip it.

Connector Health and Observability

Connector list views surface operational status signals such as active count, healthy count, and credential readiness. This makes it easier to identify weak links quickly.

In auto mode, schema snapshot features help you inspect discovered schema metadata and refresh snapshots when needed. This is helpful for diagnosing data-shape drift.

When connector behavior fails, troubleshoot in layers:

• credentials and connection details,
• provider-specific configuration,
• template parameter and operation mismatch,
• policy bounds like timeouts or row limits,
• expected identity mapping inputs.

Layered diagnosis prevents random edits and gets you to root cause faster.

Designing for Least Privilege and Stability

Connector power should be matched by connector restraint.

A strong connector setup exposes only the data needed for specific support outcomes. It limits broad reads, keeps templates focused, and avoids returning unnecessary fields. It also uses reasonable policy bounds for timeouts, row limits, and redaction where needed.

In operational terms, this makes incidents easier to contain and fixes easier to apply.

A common anti-pattern is building one huge connector scope “for flexibility.” That tends to create opaque behavior and harder debugging. Focused connector scopes are both safer and easier to maintain.

A Practical Connector Rollout Pattern

For most teams, the best rollout pattern is:

1. Pick one high-value account-aware use case.
2. Configure one connector provider for that use case.
3. Test template behavior with realistic inputs.
4. Validate scenario outcomes in Knowledge Validation.
5. Launch on limited traffic and monitor conversation outcomes.

After that path is stable, expand to adjacent use cases.

This pattern delivers value quickly while controlling risk.

Common Connector Mistakes

One common mistake is adding connectors before defining clear support questions they should solve. That leads to broad, underused configurations.

Another is skipping template tests and discovering parameter or schema mismatches in production.

A third is assuming connector success messages mean full workflow readiness. End-to-end readiness still depends on validation outcomes and routing behavior.

A fourth is overreliance on connector data for questions that should still be handled through strong knowledge sources.

Where Connectors Fit in the Full System

Connectors are one layer in the support decision stack:

• channels bring conversations in,
• knowledge provides policy and product grounding,
• connectors provide runtime account context,
• routing applies handling policy,
• conversations expose operational outcomes.

When connectors are designed with clear boundaries and tested flows, they become one of the strongest force multipliers in Jardine.

If you are implementing account-aware behavior next, continue with Runtime Context to understand identity mapping and graceful fallback behavior.