Open Letter: Pacing the Frontier and Your Association

To the association community,

On Saturday, Dario Amodei published a 3,800-word open letter calling for the AI industry to slow down. Sam Altman, Elon Musk and Demis Hassabis said they agreed. AI stocks fell. By Sunday it was the only thing anyone in our world was talking about.

We've heard from a lot of clients since. Most of what they're asking comes down to one question: does this change what we should be doing?

Mostly no. The pace of the frontier isn't something we can control. The architecture we build on is.

Where We Stand

We think the letter is right on the substance. The people closest to the capability are the ones asking for the brakes, and that should be taken seriously.

Nobody at Blue Cypress has a solution to a society-scale coordination problem. Neither does anyone else, including the people who wrote the letter.

But how your organization adopts AI determines how exposed you are to any of this. That part is within your control, and it was before this weekend.

What Happened

Two things drove the letter.

The first is that AI systems now help build the next generation of AI. That loop, recursive self-improvement, is what makes the pace hard to predict.

The second is an incident last month. A swarm of agents at a frontier lab conducted unauthorized attacks against another company. The damage was minimal. It was minimal because the agents weren't capable enough to do worse, not because anything caught them. Amodei's own read is that a more capable swarm with the same misalignment could cause damage in the hundreds of billions.

Weeks passed before the operator found out, and they found out because the target told them.

Someone on our team asked the obvious question: was this just humans trading security for speed?

Partly. Some of it was a decision about how much autonomy to grant and how much observation to build alongside it. Some of it wasn't, because the systems did things their operators hadn't anticipated.

But as an association leader, you are not running a frontier lab. Your risk isn't that your member service agent becomes superintelligent. It's narrower and more ordinary. An agent with more access than it needs, taking an action nobody approved, in an environment where nobody would notice.

That's a far smaller problem than the one the letter is about, and a much more solvable one.

What the Letter Changed for Us

We've been making the case for architectural control for years, and we've been making it on cost, flexibility and lock-in grounds. Own your data layer so a vendor can't reprice you. Keep your model options open so you can move when something better shows up. Don't tie your roadmap to a single AI Lab.

All of that still holds. What the incident adds is that the same architecture is a containment argument too. Control over which models run, where they run and what they can touch isn't only about cost and leverage. It also decides how much of somebody else's mistake can reach you.

Why MemberJunction Is Built This Way

We created MemberJunction, an open-code and completely free AI platform for associations to solve many of these problems. MJ was designed around two key assumptions. That the model layer would keep changing, and that no organization should be locked to a single AI provider's judgment about any of this.

That's why there's an abstraction layer between the platform and the models, and why we support only providers who have Zero Data Retention (ZDR) API policies. Your data isn't kept by them and isn't used to train anything. Those were safety decisions as much as architectural ones, made years before this weekend gave them a news hook.

The same thinking shows up in what we tell clients. We've been advising associations to treat AI agents as the highest-risk category in their tool inventory, and to require formal approval before an agent is connected to any association system, even for tasks that look routine.

In February we published The AI Infrastructure Trap Associations Need to Avoid, which argued that the two common paths both leave you stuck. Buy a static AI wrapper and you're holding an architecture someone froze in 2025. Build and maintain everything internally and you've signed up to track model developments forever. What we said then was that you should own your data and your data destiny, and work with someone whose job is keeping up with the models so that yours isn't.

The Four Levers

Four things decide how exposed your organization is. All four are yours to set.

Which models run. MemberJunction supports dozens of AI providers with access to hundreds of models through a single interface. You can swap models or providers without changing anything in your agents or applications. If you don't want a frontier model in a particular workflow, don't use one. In plenty of workflows the smaller, faster model is the better fit on cost and latency regardless.

Where they run. Managed by us, managed in your own cloud account, or self-hosted on your infrastructure. Dedicated to you in every case, with private databases, compute, storage and networking. You are not sharing a tenancy with anyone, ever.

What they can touch. Zero-retention terms with every inference provider we recommend. The architecture shares metadata with the models, enough for them to understand the shape of your data and run analysis. Beyond that you get to choose exactly what you share for advanced analysis. What your team does inside the system always stays in your environment, and because every product in the Blue Cypress family is built on the same MemberJunction architecture, that holds across the family rather than in one product. It also applies to custom agents built just for your association on MJ.

How much is left to the model. Just because AI can do something doesn't mean it should. A large share of what associations want from agentic systems is achievable with ordinary deterministic workflows, with AI plugged into narrow, specific decision points. Our own pattern works that way. AI proposes, a deterministic check verifies, a person approves, and from then on the approved result runs identically every time. Exploration is AI-assisted. Execution isn't. A trusted pathway is code, and code does the same thing on Tuesday that it did on Monday.

The fourth lever is the one most often skipped. The smaller the surface where a model is making an unsupervised call, the smaller the consequence when a model behaves in a way nobody expected. That holds whether the surprise comes from misalignment, a bad prompt, or an ordinary bug.

Two Things That Make the Levers Checkable

Settings only mean something if you can verify they're where you think they are.

The first is observability. A complete audit trail of who accessed what and when, role-based permissions with field-level granularity, and encryption at rest with keys you control. This is where the lab incident is most instructive. It was a detection failure before it was anything else.

The second is that MemberJunction's source is public. It's open code, licensed so you can read it, run it and keep it, and always free for the association community. You know exactly how your data is handled, the code literally tells you and independent individuals and AI agents can inspect it at will.

Recursive Self-Improvement

You're going to hear this term a lot over the next few months. Here's what it means.

Recursive self-improvement is when a system starts improving itself. It isn't science fiction and it isn't new. It's the core of what's driving the concern in the letter.

It's also a choice made at the system level. Adopting AI does not opt you into it. In an environment you control, you decide how much self-improvement your agents are permitted, and for most association workloads the right answer is none.

One note on our own language. We say MemberJunction gets better over time. That happens because the underlying models improve, and because your people approve more definitions into the system. It does not rewrite its own objectives or widen its own permissions. MJ does have facilities to automatically grow memory and learn more about your organization so that agents become smarter, more accurate, and better teammates. That memory never leaves the boundaries of your MJ instance. In addition, MJ has “self-improvement” features for example being able to improve agents based on past results. However, such improvement features always have gates that humans can review and approve.

What We'd Do This Quarter

Six things, none of which require a strategy offsite.

1. Write down every AI tool and agent with access to your systems, including AI built into software you already pay for. This list runs longer than most people expect, and the embedded AI is the part that gets missed.
2. For each one, answer three questions. What can it read. What can it do without a person approving it. Would you know if it did something else.
3. Default agents to requiring approval before they touch a production system. If you don't have a written policy, start from a template instead of a blank page.
4. Find out where your data physically sits and who else is in that tenancy.
5. Ask every vendor in writing whether your data or your staff's interactions are used to train their models. Get the answer into the contract, not off the marketing page.
6. Choose the smallest model that does the job. Usually cheaper, usually faster, and less exposed.

Number two matters most and takes the longest. It's also the question that would have surfaced the lab incident in days instead of weeks.

Where This Leaves You

None of this is a reason to slow your own adoption. The gap between associations that use AI well and those that don't is going to widen this year, not narrow. Waiting isn't the safe option. It's the one that feels safe.

Adopt aggressively. Just be deliberate about what you're adopting on. The associations that come through this in good shape will be the ones who set those four levers themselves, rather than inheriting whatever settings came with the software.

Sincerely,

Amith Nagarajan
Founder, Blue Cypress