Claude needs a working agreement, not just more tools

Claude did not get a big new button overnight. The clearest Anthropic signal is more basic: if Claude is going to become a real coworker, the team needs to write down how it may help, push back, use tools, and leave a trail. Less exciting than a release note, maybe. In practice, this is often where Claude starts becoming useful for real work.

• Source: Anthropic co-founder Chris Olah's remarks on Pope Leo XIV's encyclical "Magnifica humanitas"

Today's Claude signal: write a local working agreement

On May 25, Anthropic published Chris Olah's remarks from the Vatican presentation of Pope Leo XIV's AI encyclical. The point is not religious marketing. Olah says, fairly directly, that AI labs, including Anthropic, work under commercial, technical, and geopolitical pressure. That makes outside voices important, especially voices that can say when development is going wrong.

For a Swedish company, school, or small team, the practical translation is simple: do not let the vendor's default settings be your only AI policy. Write your own working agreement for Claude. Keep it short enough that people actually use it.

• Source: Widening the conversation on frontier AI

What a working agreement means in Claude

Claude's Constitution is Anthropic's document for the values and behaviors Claude is trained toward. It is not the same as your local instruction. A local working agreement describes how Claude should behave inside your recurring workflows.

Think of it as a practical field guide:

• When Claude may advise, and when it may only prepare material.
• Which sources are enough for a decision, and when a human must check.
• How Claude should say "I don't know" without hiding behind excessive caution.
• Which tools, files, and systems Claude may reach, and with what level of permission.
• What must be logged: prompt, source, assumption, decision, action, and reviewer.

This is a Mindset Forge question before it becomes a Tool Forge question. If the role is unclear, connecting more tools will not fix it.

• Source: Claude's Constitution

Where control should sit

Claude Code has no new user-facing feature after version 2.1.150; the latest public entry describes internal infrastructure improvements. But the Claude Code security docs still show how Anthropic thinks about real control: read first, explicit approval for edits and commands, and sandboxing when tools get access to files or the network.

MCP, Model Context Protocol, is an open standard that lets Claude talk to external tools and data sources through defined interfaces. When MCP or other connectors are used, the working agreement should get specific: use environment variables or a secrets manager for keys, grant scoped permissions, redact sensitive output, add approval gates before actions, and keep audit logs.

That is not a brake. It is what lets Claude work close to real systems without turning every prompt into a trust exercise.

• Source: Claude Code changelog
• Source: Claude Code security
• Source: Connect Claude Code to tools via MCP

Who this matters for

This is for teams that have moved past "can Claude write an email?" and are starting to ask "may Claude help inside our real work?" A consultant can use Claude to prepare proposals. A school can use Claude for lesson drafts. A service company can use Claude to triage customer cases. In all three cases, the same simple thing is needed: an agreement on what Claude may do on its own, what it may only suggest, and what a human always approves.

Start with a workflow where the benefit is easy to see, but write the boundaries so they can grow with the work.

Try this prompt this week

Use it in Claude chat or Claude desktop first. If the result will become rules for Claude Code or MCP, have a technical person translate the proposal into settings, scoped API keys, sandboxing, and logging before connecting tools.

You are our Claude work lead for one practical workflow.

Workflow: [describe recurring work, for example proposal drafting, customer-case triage, lesson planning, or code review]
Team goal: [what should become faster, clearer, or easier to review]
Systems and material that may matter: [files, folders, CRM, email, ticketing tool, codebase, documents]

Write a working agreement for how Claude may help us.

Include:
1. What Claude may do on its own.
2. What Claude may only suggest.
3. Which sources Claude must show before we trust the answer.
4. Which data fields should be masked or redacted.
5. Which tools or systems need scoped permissions, environment variables, or a secrets manager.
6. Which actions need human approval before anything is changed, sent, or published.
7. Which audit log we should keep: prompt, source, assumption, decision, action, and reviewer.
8. Three test cases: one easy case, one edge case, and one case where Claude should say no or ask for human review.

End with a short version of no more than 12 bullets that we can place at the top of our team instructions.

A good result looks like this:

• You get a short rule set that can be used in the next team meeting.
• Claude clearly separates advice, drafts, and actions.
• Tool access is described with practical boundaries, not just "be careful".
• There is at least one test where Claude should pause and ask for review.

Next step for Hammer readers

If you want to use Claude as more than a chat window, write the working agreement first and then build tool access around it. This fits especially well in Mindset Forge: pick one workflow, define what good AI work looks like, and then make a small Tool Forge implementation where permissions, redaction, approval gates, and audit logs are built in from the start.