Augmenting an organisation's Discord server with NanoClaw magic

The challenge: one organisation, many projects, and contributors who should not see everything

The organisation operated multiple projects and initiatives in parallel, coordinated through a shared Discord server, with its knowledge base in Notion and delivery tracked in Linear and git. It wanted AI assistance embedded where the work already happened — in Discord — for answering project questions, maintaining project knowledge, and reporting on progress.

The requirement that shaped the design was confidentiality between projects. The organisation's contributors included freelancers who should hold knowledge of exactly one project. A single organisation-wide assistant with access to everything would have violated that boundary by construction: whatever it knew, any user could potentially elicit. The assistance therefore had to be partitioned the way the organisation itself was partitioned — and the partition had to be enforced by the system's structure, since instructions alone do not reliably constrain what a language model reveals.

Two further constraints applied. The organisation's operational maturity and budget called for infrastructure it could actually run — the solution had to be simple to operate and inexpensive to keep alive. And the deployment had to respect the organisation's existing arrangements: Discord roles already encoded who held which appointment, and Notion already held the knowledge, so the design would work with these rather than introducing parallel systems.

The approach: partition the agents the way the organisation is partitioned

1. Begin with organisational discovery, before any deployment

The engagement opened with discovery of the organisation itself: its initiatives, its projects, and the roles and appointments within them. For an organisation this size, that discovery ran directly through the company's founder, who held the whole picture — every initiative and project, and where each one's knowledge lived in Notion. The output was the map the whole design rested on: which projects existed, which Notion pages held each project's knowledge, which Discord roles corresponded to which appointments, and who should be able to read and update what. An agent deployment inherits the clarity, or the confusion, of the organisational map it is built on — so the map came first.

2. Choose a runtime whose isolation is structural: NanoClaw

NanoClaw was selected as the agent runtime for two properties. First, its isolation model: NanoClaw runs each agent group in its own container with its own instructions (CLAUDE.md), its own memory, and only the access it is explicitly granted — separation enforced at the operating-system level rather than by application logic. Second, its setup cost: the guided installation runs from a fresh machine to a working agent without specialist skills, which matched the organisation's operational capacity and meant the deployment could be handed over.

One agent (connector) was created per project. Each agent was assigned the Notion page containing its project's data, and no agent could reach another's — the freelancer scoping requirement, expressed as architecture.

3. Layer the guardrails, and anchor them in credentials

The inter-project boundary was enforced at three levels, in increasing order of hardness:

• Instructions. Each agent's CLAUDE.md defined its project scope, its conduct, and what it should decline.
• Available connections. Each agent was wired only to the integrations its project required; connections to other projects' resources did not exist to be misused.
• Credential scope. A dedicated Notion app (integration) was created and scoped to the specific pages of each project, so that the token an agent held could not read outside its project regardless of what the agent was asked or instructed to do.

The ordering matters: instructions are a soft guardrail, and credentials are a hard one. The CLAUDE.md layer shapes behaviour; the credential layer bounds it. With NanoClaw's container isolation underneath, a confidentiality failure would have required a failure in the platform rather than a persuasive prompt.

4. Gate writes through the organisation's own role structure

Reading was scoped per project; writing was scoped per person. Updates to the knowledge base were governed by a permissions database in Notion describing whether a given Discord user — identified by their Discord role — could update documents in their project. When a user asked an agent to change project documentation, the agent checked the permissions database before acting.

The key design choice is where the permissions live: in Notion, as data the organisation already administers, keyed to Discord roles the organisation already assigns. Access control followed the organisation's existing appointment structure, and changing who could do what required editing a table rather than editing an agent.

5. Automate the daily reporting, for two audiences at once

A sync script performed a daily sync of each project's git repositories into the NanoClaw container. The daily scheduled prompt then examined Linear and the git commit history to discover what had changed, and produced a report into the project's internal Discord channel in two registers:

• Internal notes — the day's changes with technical detail, for the team;
• Release notes — the same changes described for end-users of the project.

Both were also recorded to a Notion page per project. The accumulation turned out to carry the most value: product managers assembling monthly release notes now started from a month of pre-written, dated, dual-register notes, and used Claude to compose the monthly publication from them. Previously, monthly notes had been costly enough to reconstruct — from memory, commits, and tickets after the fact — that they were often skipped or produced patchily; now they were composed reliably from notes that already existed.

6. Size the infrastructure to the need: a laptop, on 24/7

The whole deployment ran on a laptop that lived in the organisation's office, powered on around the clock. The choice was deliberate rather than makeshift: the workload — chat interactions and one daily scheduled run per project — required no more, the organisation's data stayed on premises on hardware it owned, and the operating cost was approximately the electricity. The trade-offs were accepted with eyes open and are recorded below.

The execution: sequence of the work

Phase one — discovery (the opening days). Initiatives, projects, roles, and appointments mapped; Notion knowledge pages identified per project; scoping requirements confirmed, including the freelancer constraint.

Phase two — platform and partitions (once the map was agreed). NanoClaw installed on the office machine; one agent per project created with its own CLAUDE.md; per-project Notion apps scoped to their pages; Discord wiring per project channel.

Phase three — permissions and reporting (the bulk of the build). Permissions database established in Notion against Discord roles; write-gating implemented; git sync script and daily prompts deployed; report formats settled with the teams. The early daily reports needed prompt iteration over a few cycles before the two registers read correctly — the internal notes technical enough for the team, the release notes plain enough for end-users.

Phase four — handover (to close the engagement). Operation handed to the organisation: the founder — or a designated person — administers the Notion permissions table, the organisation owns the office laptop and the sync script, and a runbook covers the operational tasks: restarting after power or network loss, adding a new project agent, and editing permissions.

What did not go smoothly

A few things took more iteration than expected.

Scoping each Notion app to exactly the right pages. Getting each project's integration scoped to precisely its page tree — no more, no less — took care: over-scoping would leak across projects, under-scoping would blind the agent. It was resolved by verifying the scope project by project against the discovery map.

Discord roles that mapped to more than one permission. Users holding multiple Discord roles created ambiguity about what they could write; the permissions model was given an explicit precedence rule to resolve it.

The single machine is a single point of failure. The always-on office laptop needed a documented restart procedure after power or network interruptions. The single-machine deployment is a limitation accepted by design — appropriate to the organisation's scale and budget, and documented so that outgrowing it is a planned event.

The results

Technical outcomes

• One isolated agent per project, live in the organisation's existing Discord, each confined to its project's Notion knowledge by credential scope and container isolation
• The freelancer confidentiality requirement enforced structurally — a contributor scoped to one project interacts with an agent that cannot reach any other
• Daily reporting automated across all projects: internal notes and end-user release notes generated each day from Linear and the git history, posted to Discord and recorded in Notion
• Write access governed by the organisation's own roles, administered as a Notion table, with no per-agent reconfiguration
• Coverage was complete for the organisation's active work — one agent per active project, each producing a daily report, running continuously on the office machine

Human and organisational outcomes

• Product managers assemble monthly release notes from a month of accumulated daily notes, using Claude for the composition — work that previously required reconstructing the month after the fact from memory, commits, and tickets, costly enough that it was often skipped
• Progress became visible daily without anyone writing status updates — the reporting reads from the work itself (commits and Linear), so visibility stopped depending on discipline
• The organisation operates the system itself: the permissions table, the agents, and the machine were handed over with documentation, within the operational capacity the design was sized for
• Routine project questions stopped interrupting the leads — the per-project agents absorbed them, and a freelancer scoped to one project could self-serve against that project's agent without gaining any visibility into another

What this means if you're running a startup or SME

The general point: an AI deployment inherits its shape from the organisation — the boundaries, roles, and knowledge structure have to be mapped first, and then enforced in the architecture rather than in the prompt.

Two elements of this case generalise. The first is the guardrail layering: instructions, available connections, and credential scope, in that order of hardness — an agent that must not see something should hold a credential that cannot read it. The second is the fit-for-purpose sizing: a laptop in an office is a perfectly sound platform for an organisation whose workload is conversations and a daily scheduled run, and the discipline is in documenting the trade-off rather than avoiding it. AI adoption fails more often from mismatched ambition than from insufficient technology.

This is the work we do at Aijutsu under our AI readiness and adoption sprints: discovering how an organisation actually runs — its projects, roles, and boundaries — and deploying AI assistance that respects those boundaries structurally, on infrastructure the organisation can own and operate.

If your organisation wants AI in its daily workflow while keeping project knowledge partitioned — including from some of its own contributors — that is a solved problem. Book a diagnostic conversation: [email protected]

Frequently Asked Questions

What is NanoClaw?

NanoClaw is an open-source runtime for personal Claude agents built on Anthropic's Claude Agent SDK. Each agent group runs in its own isolated container with its own instructions, memory, and explicitly granted access — isolation enforced at the operating-system level — and connects to messaging channels such as Discord, Slack, Telegram, and WhatsApp. It was chosen in this case for that isolation model and for a guided setup requiring no specialist skills.

How do you add a Claude AI agent to a Discord server?

Through an agent runtime with a Discord channel adapter — in this case NanoClaw, where a Discord connector pairs the server to an agent running in an isolated container. The organisational work matters more than the wiring: deciding which channels map to which agents, what knowledge each agent holds, and which roles may do what through it.

How do you stop an AI agent from accessing data it shouldn't?

Enforce the boundary below the level of instructions. In this case the isolation was layered: each agent's instructions defined its scope, each agent held only the connections its project required, and each agent's Notion credential was scoped to its project's pages — so no phrasing of a request could produce access the token did not have. Instructions shape an agent's behaviour; credentials bound it.

How do you control which users can update a knowledge base through an AI agent?

Key the permission to an identity the organisation already manages. In this case a permissions database in Notion recorded whether a Discord user — identified by their Discord role — could update documents in their project, and agents consulted it before writing. Administering access meant editing a table, with no changes to the agents themselves.

Can AI generate release notes automatically?

Yes, from the work's own records. In this case a daily scheduled prompt read Linear and the day's git commit history and produced two registers of output — internal notes with technical detail, and release notes written for end-users — posted to Discord and accumulated in Notion, from which product managers composed monthly release notes using Claude.

Do you need cloud infrastructure to run AI agents?

The workload decides. An organisation whose agent workload is chat interactions and daily scheduled runs was served in this case by a single always-on laptop in its own office — data on premises, operating cost near zero — with the single-machine trade-off documented deliberately. Cloud hosting becomes worthwhile when availability requirements or workload outgrow that, and a well-documented small deployment makes that migration a planned event.