A shared assistant for your team

This mini-book is for Level 3 Builder. Colleagues will depend on an assistant you configure. If its sources, permissions, or instructions are wrong, several people can create the same bad document before anyone notices.

2. Four assistants, four rules, no owner

Four people in your group use four different assistants. One pastes a customer list into a personal account. Another has an approved workspace but copied an old prompt from a colleague. A third believes the tool is EU-hosted but cannot say whether that describes file storage, model inference, or both. Nobody knows who should remove stale instructions.

The team asks you to make one shared assistant. A shared prompt sounds like the solution, but sharing changes the job. You are no longer improving your own chat. You are creating a maintained service with users, permissions, source material, expected outputs, failure cases, and an owner.

Start with a draft-only assistant for one bounded task. Give it synthetic sources, a curated instruction, two user roles, and a written usage rule. Test both a supported request and a request it must refuse. Only then consider wider data, integrations, or rollout.

3. After this you can

• Configure one bounded assistant that at least two colleagues can use consistently.
• Assign an owner, editor, user group, review point, and removal process.
• Separate shared instructions, approved sources, user input, and external actions.
• Test supported, missing-evidence, correction, action-refusal, and unauthorized-access paths.
• Explain whether vendor hosting, stored data, and model inference remain in the EU.

4. Prerequisites

• T02-L02 · Your daily driver.
• T12-L03 · Governance that people follow.
• An approved test workspace with permission to create an assistant shared only with a named test group.
• Two test users with ordinary user roles; do not give them administrator access for convenience.
• One named agent owner and a named backup workspace administrator who can remove access or disable the assistant.
• Synthetic files only for the exercise.

Do not connect a mailbox, drive, customer system, laboratory system, contact list, publication channel, or production knowledge base. Do not test permissions using real confidential or regulated data.

5. The idea in one page

A shared assistant is a small product. Define its operating contract before selecting settings.

The weakest user sets the practical boundary

The assistant must remain safe when used by the busiest colleague, not only by its builder. Put essential constraints in the shared instruction and interface. Do not depend on everyone remembering an onboarding conversation. Keep the allowed task small enough that a new user can recognise an unsupported answer.

Users and editors need different permissions. Users run the approved task. Editors change instructions and sources. Administrators manage workspace-wide access and integrations. Giving every user the highest role converts ordinary mistakes into system-wide changes.

Use groups when the approved workspace supports them. Test removal as carefully as addition and record which sharing or account control actually ended access.

A prompt library needs editorial ownership

A shared prompt is maintained content. Give it an ID, owner, version, review date, input, output contract, and tests. Deprecate old prompts visibly.

Personas should describe work, not pretend the system has professional authority. Draft an internal literature-triage record is useful. Act as our legal approver grants imaginary status and obscures who remains accountable.

“EU-hosted” has several layers

Ask separately where the contracting vendor is established, where application data and backups are stored, where model inference runs, which subprocessors receive data, and whether search, OCR, integrations, support, or telemetry cross regions. An EU company can route inference globally. An EU data centre can still rely on non-EU subprocessors or support paths.

Current vendor check — last verified 4 September 2026. Langdock's public terms state that customer data is stored on EU servers and describe its Azure deployment as hosted in Frankfurt unless otherwise agreed. They distinguish EU and global model deployments, so EU-only inference requires an EU-deployed model. These vendor statements do not prove that a workspace is configured or legally approved. Verify the signed agreement, selected deployment, enabled features, live subprocessors, and your organisation's decision.

6. The worked example: release one bounded shared assistant

Use an approved Langdock test workspace or an equivalent platform that exposes ownership, instructions, sources, user/editor roles, evaluation records, and administrator shutdown. The durable outcome is the contract and evidence, not a particular menu layout.

Create an assistant called Shared Evidence Drafter — Synthetic. It may draft an internal evidence record from supplied synthetic sources. It may not browse, connect to another system, send, publish, approve, or make a decision.

Before configuration, verify procurement assumptions. A data processing agreement is relevant when a provider processes personal data for an organisation; responsible legal or privacy staff must assess the actual contract and use case. Compare seat and usage cost over one realistic month, including active users, runs, model charges, administration, support, unused seats, migration, and exit effort. Verify a current quote rather than publishing a price that will age quickly.

Common configuration

Assign these roles:

Agent owner: assistant-owner@example.invalid
Backup workspace administrator: service-backup@example.invalid
Editors: Evidence Assistant Maintainers
Users: Evidence Assistant Testers
Review date: 2026-10-02

The addresses use the reserved .invalid domain. Replace them only with approved internal identities when performing an authorized real deployment.

Use this release sequence in the current interface:

1. Create a private assistant and record its generated ID or permanent link.
2. Confirm its single owner, add the approved test group with user access and the maintainer group with editor access, and do not enable workspace-wide sharing.
3. Add each synthetic source separately so its filename and review date remain visible.
4. Save the shared instruction with its version in both the platform and release record, then use Create to publish the first active agent version. This product-level publication makes the restricted agent usable; it does not authorize the agent to publish content externally.
5. Have ordinary User A and ordinary User B each run the same four fixed requests. Save every input and raw output under the tester identity and prompt version in the release record. If Agent Evals is available, mirror the four cases in one test set, run it as an editor, and retain the run or downloaded CSV.
6. Remove User B from the test group and verify access denial. While User A retains access, have the backup workspace administrator open the agent in Governance, locate Disable, and record that the control is reachable without activating it. Langdock documents that disabling makes the agent unusable until an editor publishes a new version and an administrator approves it again; do not disable the release candidate merely to prove that consequence.

Button names vary, so retain evidence of the resulting role, source, instruction, test, access-removal, and disable-control states rather than relying on one screenshot of a menu.

Create shared instruction version SEA-001 v1.0:

Purpose: create an internal evidence draft from the sources supplied in this assistant.

For every factual statement, return:
- Finding: one supported sentence
- Evidence: the source ID and exact supporting phrase
- Status: supported or needs_review

If evidence is missing, conflicting, stale, or outside scope, use needs_review.
Do not search the web, use unlisted knowledge, infer approval, or invent a fact.
Do not send or publish content, modify a system, or address an external recipient.
End every response with: Draft — human review required.

Keep version, owner, review date, and tests beside the instruction. Do not rely only on edit history inside the platform.

Lab framing: literature triage and manuscript editing

Attach three synthetic files.

L-17-literature-records.md

Source L17-A | reviewed 2026-09-01
Title: Northstar preparation comparison
Evidence phrase: “Sequence B reduced the fictional preparation time by 12 minutes.”
Limit: synthetic workflow fixture; no scientific conclusion.

Source L17-B | reviewed 2026-09-01
Title: Cedar correction notice
Evidence phrase: “The original Table 2 labels were reversed.”
Limit: cite the correction together with the original record.

L-17-style-rule.md

Audience: internal manuscript working group
Use source IDs in every evidence line.
Never turn a workflow fixture into a scientific claim.

L-17-manuscript-draft.md

Draft sentence: Sequence B improved the experiment and should be used in future work.
Revision purpose: remove unsupported interpretation while preserving the supplied comparison.

Run four tests:

The assistant supports triage and internal editing; it does not decide what to cite. Each tester runs all four cases; they then swap raw outputs and compare every factual phrase with the files. The owner records tester identity, failures, and prompt version.

Keep SEA-001 as the assistant's only instruction. Create SEA-002 v1.0 as a shared Prompt Library prompt, share it only with the tester group, and invoke it in the agent chat:

Revise only the supplied manuscript sentence. Preserve supported facts and uncertainty.
Remove recommendations or conclusions not present in the named evidence source.
Return: Revised sentence; Evidence source and quote; Change made; needs_review.
Do not add a citation, result, or recommendation.

Ask it to revise the sentence in L-17-manuscript-draft.md against L17-A. A passing revision may state that Sequence B reduced the fictional preparation time by 12 minutes, but it removes “improved the experiment” and “should be used” because neither conclusion is supported. The evidence line quotes L17-A, and the change log names both removals. This tests actual manuscript editing and the shared prompt without pretending the agent has two instruction configurations.

Company framing: an internal account evidence draft

Use the same assistant contract with two different synthetic files.

C-04-account-records.md

Source C04-A | reviewed 2026-09-02
Completed: draft navigation and two test pages
Open: mobile review and accessibility check
Decision: choose one of two fictional colour directions
Delivery date: not approved

C-04-usage-boundary.md

Audience: internal account team
No customer contact, commercial terms, delivery promises, or approval claims.
Every output is reviewed by the named account owner.

Run the parallel tests:

The same four cases make Lab and Company results comparable. The factual skin changes; ownership, permissions, source boundary, review, and refusal behaviour remain fixed.

Verify access with two ordinary users

Before removal, User A and User B should each run the assistant and see approved shared content but should not edit instructions, add an integration, broaden sharing, or change model deployment. User B should then be removed from the test group and lose access while User A retains access. The backup workspace administrator should inspect the Governance record and reach the Disable control without help from the agent owner; leave the passing release candidate enabled.

Capture the role, source, instruction version, four test results, deployment region selection, enabled capabilities, and review date in one release record. Do not capture account secrets, real names, customer data, or private URLs.

Write the one-page usage rule

Use this compact structure:

Assistant: Shared Evidence Drafter — Synthetic
Agent owner / backup administrator: [approved identities]
Allowed users: [group]
Allowed task: internal evidence drafts from listed sources
Forbidden input: personal, confidential, regulated, credential, or unapproved data
Forbidden action: sending, publishing, approval, external changes, unapproved search
Required review: compare every finding and quote with its named source
Failure response: mark needs_review; report repeated failures to owner
Prompt/source change: editor only; rerun all four tests
Review and retirement date: [date and owner]

Both test users read the rule before access is retained. If they interpret an item differently, revise the rule and rerun the affected test.

7. What goes wrong

Nobody owns the assistant

Symptom: stale sources remain, failed runs are ignored, and nobody can disable the assistant when the builder is absent.

Fix: name one agent owner plus a backup workspace administrator with authority to remove access and stop use. Record the handover and review date.

The prompt library grows without curation

Symptom: users choose different copies of the “same” instruction and produce inconsistent records.

Fix: keep one canonical prompt ID, version it, archive replacements, and rerun the fixed test set after every change.

An EU brand is mistaken for EU processing

Symptom: the team can name the vendor address but not the storage region, inference deployment, or subprocessors.

Fix: verify each processing layer contractually and in workspace configuration. Record unknowns as blockers.

Everyone receives administrator access

Symptom: an ordinary user can change sources, models, sharing, or integrations while trying to run a draft.

Fix: test separate user, editor, and administrator roles. Remove privileges that the normal task does not require.

Sharing is broader than the source licence

Symptom: every workspace member can use a source intended for one group or project.

Fix: align source access with the narrowest approved audience. A shared assistant cannot broaden document rights.

Missing evidence produces a polished guess

Symptom: the assistant answers the easy case but invents a date, instrument, approval, or customer promise in the negative test.

Fix: preserve the failed output, tighten the source boundary, and rerun all tests. Do not silently edit the answer and call the assistant fixed.

Rollout begins before a usage rule exists

Symptom: users learn constraints from one another after access has already spread.

Fix: make the one-page rule part of the release artifact. Broader onboarding and adoption work continues in T13-L03.

8. Do it yourself: a two-user release in 60 minutes

Minutes 0–10: choose one draft-only task. Name one agent owner, a backup workspace administrator, ordinary user group, editor group, review date, and explicit forbidden actions.

Minutes 10–20: prepare two short synthetic sources and instruction v1.0. Add source IDs, reviewed dates, missing-information behaviour, output shape, and human-review line.

Minutes 20–30: configure the initially private assistant, publish its first active agent version, then share it only with the named test group. Disable or omit web search, connectors, workspace-wide sharing, public links, external sending, content-publication actions, and other external actions. Select an approved EU-deployed model, not a global deployment. Write a four-line rationale naming the vendor establishment, application-data region, model-inference region, and relevant subprocessors. If any required layer cannot be verified, stop and record the EU-hosting choice as blocked.

Minutes 30–40: have both ordinary users run the same supported, missing, boundary or correction, and action tests. Keep inputs and outputs. Fix the shared instruction, not individual answers, then rerun the complete set with both users.

Minutes 40–48: confirm both users can run the assistant but cannot edit instructions or broaden authority. Remove one user and verify that access ends while the other still has access.

Minutes 48–55: complete the one-page usage rule. Ask the backup administrator to locate the Governance stop control and explain the failure path.

Minutes 55–60: assemble the release record, remove accidental identifiers, and schedule the next review. Do not expand data or integrations during this exercise.

9. Exit check

Deliver exactly one artifact: one shared-assistant release package containing the working group-restricted assistant and its one-page usage rule with one named agent owner and a named backup workspace administrator.

It passes when each of two ordinary users has run all four tests and cannot edit or broaden the assistant, every supported claim points to a synthetic source, missing/action requests are refused or marked needs_review, one removed user loses access while the retained user still succeeds, the configured EU-deployed model and four-layer hosting rationale are recorded, and the backup administrator can reach the documented Disable control in Governance. The package fails if the release candidate is left disabled or any real sensitive data appears in its evidence.

10. Rule to remember

Shared means someone owns it.

11. Further reading & tools

• Taught: Langdock agent configuration (opens in a new tab) — current instructions, knowledge, model, sharing, and publishing behaviour.
• Taught: Langdock Prompt Library (opens in a new tab) — create, version, group-share, and invoke the second curated prompt with an agent.
• Catalogued: Langdock Agent Evals (opens in a new tab) — optional structured test sets, retained runs, and CSV results for the four cases.
• Taught: Langdock agent governance (opens in a new tab) — administrator inspection, review, and disable behaviour.
• Catalogued: Langdock workflow introduction (opens in a new tab) — optional next step for a visible repeatable workflow boundary.
• Taught: Langdock workspace permissions (opens in a new tab) — current role and sharing guidance; verify availability in the intended workspace.
• Catalogued: Langdock terms (opens in a new tab) and DPA (opens in a new tab) — vendor statements used for the dated EU-processing check; contractual and legal review remain required.
• Catalogued: NIST AI Risk Management Framework (opens in a new tab) — provider-neutral risk and control framing.
• Catalogued: OpenRouter documentation (opens in a new tab) — optional model-routing comparison; not used in this draft-only build.
• Taught: T02-L02 · Your daily driver — review the personal workspace boundary before sharing configuration with a team.
• Catalogued: T04-L02 · A knowledge base your team can ask — continue when approved sources need a maintained retrieval boundary.
• Catalogued: T02-L04 · A self-hosted assistant — compare a controlled deployment when hosted processing is unsuitable.
• Catalogued: Tools index — compare current product capabilities only after ownership, data scope, and tests are defined.