Connecting Avery NXR to your existing stack without breaking it

A common concern when teams evaluate Avery NXR: "We have a working stack. Slack, HubSpot, Gmail, Linear, Notion, all connected to each other through years of accumulated integrations. Won't adding an AI agent layer make this fragile?"

It's a fair concern. We've seen teams adopt new tools that broke their existing automation. The fear isn't theoretical.

Here's how Avery NXR connects to existing stacks without making them more fragile — and the principles we used to design the connection model.

The principle: agents are observers, not replacements

Most "add an integration" stories go badly because the new tool tries to REPLACE existing functionality. New CRM replaces old CRM. New project tool replaces old project tool. The migration is painful, partial, and leaves teams worse off for months.

Avery NXR doesn't replace your existing tools. It connects to them as a READER (and in some cases, a writer) for specific workflows.

Your HubSpot stays your CRM. Avery NXR reads from HubSpot to power the Carlos pipeline digest. Your Linear stays your issue tracker. Avery NXR reads from Linear to power weekly status reports.

The existing tools keep doing what they do. Avery NXR adds an AI layer that operates on top.

What "connect to existing stack" actually means

When you install Avery NXR and connect, say, your HubSpot:

→ OAuth flow grants Avery NXR specific read/write permissions you select → The connection is stored in your OS keychain → Avery NXR agents that need HubSpot data can now read from it → HubSpot continues to operate exactly as before for your team → Your existing HubSpot integrations (Slack alerts, marketing automation, etc.) continue working

Nothing about your HubSpot setup changes. Avery NXR is a new READER, not a replacement.

This is true for all 63 connectors. Slack, Gmail, Linear, GitHub, Notion, Stripe — adding the Avery NXR connection doesn't change the source system's behavior.

What permissions Avery NXR actually requests

We try to be minimal with permissions. When you connect a service:

→ Read-only by default for most connectors. The agent can read data. It can't change anything in the source system.

→ Specific write permissions only when needed. If an agent needs to send email via Gmail, you grant send permission specifically. If an agent only reads email, no send permission is needed.

→ Scoped to specific channels/folders/projects when possible. Slack permission can be scoped to specific channels rather than full workspace access. Gmail can be scoped to specific labels.

→ Revocable at any time. You can disconnect any service from the Avery NXR settings, or revoke from the source service's app permissions (Google account, Slack workspace admin, etc.).

This minimal-permission model means your security posture stays tight even as you add agents.

What happens when source systems change

A risk in any integration: the source system changes its API, your integration breaks.

How we handle this:

→ Connector versioning. Our connectors target specific API versions. When source systems release new API versions, we test and update.

→ Graceful degradation. When a connector breaks (rare but happens), agents using it produce clear error messages, not silent failures. You know what's broken.

→ Audit ledger captures the failure. When something goes wrong, the audit ledger has the details. Debugging is straightforward.

→ Fallback paths. For critical workflows, you can chain a fallback (if HubSpot connector fails → use a webhook or email-based alternative).

This isn't perfect. Integrations occasionally break. But the failures are visible and recoverable, not silent and cascading.

What we explicitly DON'T do

To avoid making your stack more fragile, Avery NXR avoids several patterns that could cause problems:

We don't proxy your existing integrations. Your Slack-to-HubSpot integration via Zapier doesn't pass through Avery NXR. We're a parallel reader, not a man-in-the-middle.

We don't require you to disable existing automations. You can keep Zapier, Make, native integrations, custom scripts all running. Avery NXR adds capability without subtracting any.

We don't bulk-modify your existing data. Agents work with data they're configured to touch. They don't go scanning your databases and rewriting records.

We don't require new accounts. Avery NXR uses your existing OAuth-authenticated accounts. We don't create parallel identities or require team members to set up new accounts in source systems.

We don't share data between customers. Even if you and another Avery NXR customer both connect to HubSpot, your data doesn't mix. Local-first architecture means there's no central place for cross-contamination.

What this looks like for a real team

Let me describe a typical 30-person company adopting Avery NXR while keeping their existing stack:

Existing stack (unchanged): → Slack (team communication) → Gmail / Google Workspace (email, calendar, docs) → HubSpot (CRM) → Linear (engineering) → Notion (documentation) → Zendesk (support) → GitHub (code) → Vercel (deployment) → Stripe (billing) → Various Zapier integrations between these

What they add (Avery NXR Pro): → Avery NXR running on Railway (their existing infrastructure) → Pro tier subscription for 25 users → Local model via Ollama → Connectors: HubSpot (OAuth), Gmail (OAuth), Slack (OAuth), Linear (OAuth), Zendesk (API key), GitHub (OAuth)

What changes: → 12 agents now running (7 templates + 5 custom) → Slack channels see agent-generated messages (pipeline digests, competitor alerts, etc.) → Email triage happens via Sophia → Support ticket triage happens via Priya

What doesn't change: → Slack still works exactly as before → HubSpot is still their CRM, no data migration → Zapier integrations still active → Team's day-to-day workflows mostly unchanged → New employee onboarding doesn't add Avery NXR as a "you must learn this tool" — agents just produce outputs people consume in Slack/email

After 3 months, the team's stack is largely the same. Avery NXR has been added as a layer, not a replacement.

The migration question

What if you actually DO want to migrate away from existing tools?

That's possible too, but it's a separate decision. Avery NXR can replace some specific AI-flavored SaaS subscriptions (Otter, Crayon, Intercom Fin) where the workflow is now handled by agents. That's the cost-savings story (covered in [post 143]).

But the choice to migrate is yours, made deliberately, after you've validated the agents work for those specific workflows. We don't force migration. We add capability, you migrate IF and WHEN it makes sense.

What we'd tell teams worried about complexity

Adding Avery NXR to your existing stack is more like adding Datadog than like adding a new CRM. It observes your existing systems and adds capability on top. It doesn't force you to redo your existing setup.

The integration burden is small:

→ Initial connector setup: ~5-10 minutes per connector you want to use → Ongoing maintenance: connectors are managed by us, you don't maintain → Permission scope: you control exactly what Avery NXR can see and do

If your existing stack works well and you don't want to change it, Avery NXR can be added without changing it. The agents operate alongside your existing workflows.

What about my Zapier (or n8n, or Make) setup?

For teams that already have workflow automation:

→ Keep it running. Avery NXR doesn't compete with simple SaaS-to-SaaS automation. Use Zapier/n8n/Make for what they're good at (cross-tool data plumbing).

→ Use Avery NXR for the AI-heavy workflows where local-first agents add value.

→ Some teams eventually migrate AI-heavy workflows from Zapier to Avery NXR (cost savings, output quality, audit transparency). Simple non-AI workflows tend to stay in Zapier.

The decision about where each workflow lives is per-workflow, not all-or-nothing.

The principle

When buying new tools, the question shouldn't just be "does this tool do X?" but also "does adding this tool make my overall stack more fragile?"

For Avery NXR, the answer to the second question is: no, because we're designed as an observer layer on top of existing systems, not as a replacement that requires you to redo your setup.

This design choice costs us some functionality. We can't deeply own data the way a replacement tool could. We can't drive workflows that require deep integration with source systems.

We think the trade-off is right. Most teams have working stacks they don't want to disrupt. Avery NXR adds capability without forcing disruption. The adoption path is friction-free because nothing has to break.

→ avery.software — Free Desktop tier. Connect to your existing stack without rebuilding it.