Build one AI worker once. Then share it properly.

It is easy to ask the wrong question when AI tools get more capable: which agent should we buy?

A better question is often: which repeated piece of work should become a shared building block, so the team does not have to recreate it in every chat?

Notion's latest update about shared Notion Workers makes that question more concrete. A Worker is not a polished prompt. It is a small Node/TypeScript routine that can sync data into Notion, give Notion Custom Agents new tools, or receive webhooks from other systems. On July 9, Notion also highlighted that Workers can now be shared across a team, either so teammates can connect them to their own Custom Agents or so they get full access and can improve them.

Source: Notion, "Share Notion Workers across your team"

That sounds technical. It is technical. But the useful lesson for a smaller team is very practical: do not build five private AI solutions for the same recurring task. First write down what the building block should do, who may use it, which systems it may touch, and how the result should be reviewed.

Then a technical teammate, an AI coding agent, or an external partner can build the Worker itself. The team has already decided the work.

What a Notion Worker means in plain language

A Notion Worker is a small programmed helper that runs in Notion's environment. It can fetch information from an external system on a schedule, expose a new tool to a Custom Agent, or react when another system sends an event.

Notion's own documentation describes three main uses:

• sync external data, for example from Salesforce, Stripe, GitHub, or other APIs, into Notion databases
• give Notion AI new tools, such as "create a Jira ticket" or "look up a customer in our CRM"
• receive webhooks from services such as GitHub, Stripe, or Zendesk

Source: Notion Developers, "What are Notion Workers?"

The point is not that everyone in the office should start writing TypeScript. The point is that AI work is starting to get an operating shape. A prompt may be enough for a one-off task. A Worker becomes more interesting when the same task repeats, needs the same data source, the same review step, and the same trace every week.

Think quote requests, support cases, course registrations, receipt data, recurring meeting follow-up, or customer lists that need to become work cards. That work often gets spread across email, spreadsheets, chats, and memory. A shared Worker can become the link between the systems and the team workspace, but only if the team first defines what it is allowed to do.

Do not only share the prompt. Share the job role.

There is a maturity difference here.

An immature AI flow looks like this: someone on the team has a good prompt in a private chat. That person gets better drafts, faster summaries, and a bit less admin noise. The rest of the team does not know exactly how it works. When that person is away, the habit stops.

A more useful flow looks different. The team has a named work card: "turn incoming quote requests into reviewable proposals" or "collect overdue invoices into a prioritized follow-up list". There is an owner. There are sources. There is a stop point before anything goes to a customer. There is a simple log of what the AI did and what the human changed.

This is where Notion's sharing model is interesting. The update separates Can connect from Full access. The first level lets others use the Worker in their Custom Agents. The second lets them improve it or adapt it to a new problem.

For a smaller team, that is a useful mental model even if you do not use Notion today:

• User: may run the approved building block in a clear workflow.
• Maintainer: may change instructions, data sources, fields, and logic.
• Owner: is responsible for whether the flow is still correct, safe, and worth the time.

It sounds simple, but it solves a common problem. AI experiments often get stuck between two modes: loose chats with no owner, or big integration projects nobody has energy to start. A Worker catalog is the middle layer. Concrete enough to be useful, but not so large that it becomes a six-month systems project.

Write a work card before the first line of code

Before anyone builds a Worker, write a work card. It should be short enough to fit on a Notion page, in a Google Doc, or in a ticket. The point is that the team can say yes or no to the job role before anybody connects systems.

Use these fields:

• Name: what the building block is called in everyday language.
• Job: which recurring task it should help with.
• Input: which sources it may read, for example form responses, CRM rows, invoice status, or meeting notes.
• Output: what it should create, for example a work card, a reply draft, a prioritized list, or an updated database row.
• Allowed actions: what it may do by itself.
• Needs human approval: what it must never do without review.
• Permission: who may connect it, who may change it, and who owns the result.
• Run receipt: which fields should be logged every time it runs.
• First test: which concrete weekly task you will test it on.

This is not bureaucracy. It is how you make AI use faster without losing control. Once the work card exists, implementation can be much narrower. The builder does not have to guess. The team does not receive a magic box nobody dares to change.

Copy-paste prompt: create a Worker card

Paste this into any AI tool. Replace the brackets.

You are a practical AI architect for a small Nordic team.

We want to decide whether a recurring task should become a shared AI building block, such as a Notion Worker, a Zapier/Make automation, or a similar internal tool.

Task: [describe the task]
Team: [who uses the result]
Systems and sources: [email, forms, CRM, spreadsheet, Notion, finance system, learning platform]
Desired result: [work card, reply draft, follow-up list, report, updated database]
Things the AI must not do without human approval: [send to customer, book, delete, change price, publish, update finance data]

Create a Worker card with:
1. everyday name
2. exact job
3. input sources
4. output fields
5. actions that can be automatic
6. actions that always need human approval
7. suitable permission: user, maintainer, owner
8. run receipt with date, sources, action, error, human change, and next step
9. a first test we can run this week without disrupting customers or normal operations
10. three questions we must answer before building anything

Keep it short, concrete, and free from sales language.

This is deliberately not a coding prompt. It creates a decision brief. If the card makes sense, the next step can be technical: a Notion Worker, a Zapier automation, a Make scenario, an Apps Script, or a simpler internal integration.

Three workflows where a shared building block can pay off

Start where the same task repeats and where the output gets better when everyone uses the same template.

1. Quote request to reviewable work card

A customer fills out a form. The Worker fetches the form response and creates a work card with the need, budget signal, missing questions, and proposed next step. It can also create an email draft, but not send it. A human reviews tone, price, and promise.

This fits teams that lose momentum between "interesting lead" and "we replied in time".

2. Payment status to follow-up list

A Worker or similar automation pulls open invoice rows from a finance system or an exported list. It groups them by due date, customer type, and previous contact. The output is not an automatic collection email. It is a prioritized list with a suggested tone: friendly reminder, clarification question, or internal escalation.

There is a clear human stop point. The AI may sort and prepare. The team decides what gets sent.

3. Course or school material to exercise cards

A teacher, course lead, or trainer adds a lesson plan, PDF, or notes. The building block creates exercise cards with level, goal, material, time estimate, and what needs review. The result lands in a shared workspace instead of a private chat.

It does not replace the teacher. It makes reusable preparation visible.

Keep the integration brave and orderly

AI workflows become useful when they get real context. They become messy when access grows without ownership. Keep the controls close to the work card.

Give read access when reading is enough. Put API keys and tokens in environment variables or a secret manager, not in chat messages. Use separate accounts or scoped keys when possible. Let write actions require approval until the team can show that the flow works. Redact fields that the task does not need. Log sources, errors, human changes, and next steps.

That is not a brake. It is what lets more people on the team trust the building block.

Notion's Workers documentation also mentions secrets, OAuth, and code running in a sandboxed Node.js environment. Those are technical details, but they point to the right habit: integrations need a proper place for access, not scattered credentials in private prompts.

Source: Notion Developers, "What are Notion Workers?"

What Hammer would do first

If we helped a smaller team with this, we would not start by building a catalog of ten Workers.

We would pick one recurring task where the gain is easy to see: quote requests, support follow-up, invoice checks, meeting decisions, or course material. Then we would write the work card, choose a clear owner, and build a first version that does one job well.

This is a natural Tool Forge question when systems need to connect. It is also a Skill Forge question when the team needs to learn how to review run receipts, improve instructions, and know when the AI should stop.

The point is simple: when AI work repeats, it should not live in someone's private chat. It should have a name, an owner, an access level, and a receipt. Then the team can share the work, not just share the prompt.