Department agent teams — a pattern

The pattern is simple: one agent team per department. Each team watches for events the department cares about, suggests what to do next, and drafts the first version of the work product. People approve, edit, decide.

This is the operating model the orchestration layer was built for. NBS is deploying it in Tokyo this week. The same pattern could fit naturally on top of ShipDC / IoS-OP — the neutral data exchange Class NK already owns through its wholly-owned subsidiary, with NYK / MOL / K-Line / ONE already connected. The data substrate exists; an agent layer could sit above it.

The pattern

                  Department of Class NK
                          │
                          ▼
            ┌─────────────────────────────┐
            │   Agent team for this dept  │
            │                             │
            │   • Watcher agent           │
            │   • Suggester agent         │
            │   • Drafter agent           │
            │   • Audit logger            │
            └─────────────────────────────┘
                          │
                          ▼
                  Human at the desk
                  (surveyor / editor / coordinator)
                          │
                          ▼
                  Reviews · approves · decides

Each agent is a discrete skill. Each handoff is logged. The human stays at the decision point. The team handles the volume.

Three concrete department examples

Department example 1 — Rule maintenance

The rule maintenance team watches IMO publications (SOLAS, MARPOL, sub-committee circulars) and Class NK internal rule revisions.

• Watcher — monitors IMO and Class NK publication feeds
• Analyzer — identifies affected rule chapters, cross-references existing text
• Drafter — proposes update text in red-line format
• Audit logger — full chain preserved

The rule editor reviews drafts and approves, amends, or rejects. The first internal review of an IMO amendment happens in hours, not weeks. (Same chain as the Rule Change-Tracker — the rule maintenance department is its operational home.)

Department example 2 — Customer service / client request handling

The customer service team handles a daily stream of client requests: interpretation questions, evidence submission queries, schedule changes, certificate clarifications.

• Triage agent — classifies the request (urgent vs routine, surveyor vs admin)
• First-level check agent — for routine queries, drafts a response citing the relevant Class NK rule or policy
• Routing agent — for surveyor-needed cases, identifies the right person and tracks turnaround
• Follow-up agent — chases stuck threads, escalates when SLA is at risk

A senior coordinator reviews the auto-drafted responses, approves the routine ones, and handles the judgment calls. Throughput per coordinator multiplies. SLA breaches drop.

Department example 3 — Defect handling / casefile management

When defect data is uploaded — from a survey, an audit, a vessel incident report — the defect handling team opens or updates a casefile and runs first-level analysis.

• Intake agent — ingests the defect record, normalises against Class NK taxonomy
• Validator agent — checks against rules, flags anomalies
• Casefile agent — opens / updates the appropriate casefile, links evidence
• Status agent — tracks rectification, sends reminders, closes the loop when evidence of fix is submitted

The casefile pattern is the same one MetaWeave runs today for ship-operator clients — adapted for the inside of Class NK rather than the outside. (See we already live in your world for the outside version.)

Why this fits established organisational structure

This is not an organisational-change pattern. Every existing department would keep its shape, its people, its reporting line. What changes is the work product per person.

• No re-org
• No staff displacement
• No new reporting lines
• No external dependency

Every surveyor, every rule editor, every coordinator could have a team that handles their routine workload. They move from doing the volume to directing the volume.

This maps to the established organisational principle that the senior is responsible for the team’s output while the team does the execution. Here, the team is part-human, part-agent. The human remains responsible. The output capacity grows.

One department at a time

You do not have to deploy this everywhere at once. Pick one department where the routine load is heaviest. Try the agent team there for one quarter. Measure throughput, quality, and team feedback. Then decide whether to extend.

The Lilliput-office image — applied here

The image on the homepage shows one person at a desk, with small kawaii agents around them, each working on a sub-task. The person directs; the agents execute.

That is the department agent team pattern. Replace “person” with surveyor, rule editor, coordinator, or technical reviewer — and the picture stays the same.

What a starter deployment would need

If a pattern like this were ever pursued — entirely Class NK’s call — a starter deployment for one department would need:

1. One department willing to be the first (defect handling and customer service both have high routine volume; Class NK knows which would suit best)
2. 3–5 people in that department willing to give weekly feedback for the first quarter
3. Read access to the data feeds the department uses today

That’s the scope of work. The agent team would wire in roughly two weeks; a pilot quarter would tell you whether to extend.

Open questions a pattern like this would surface

1. Which department first? Defect handling has clear data shapes and immediate quality feedback; customer service has high volume and obvious time-savings. Class NK knows which would suit.
2. Where do agents write? Into existing Class NK internal systems (deeper integration, slower start), or into a parallel surface for the first quarter (faster start, integration later)?
3. Approval gates — which decisions require human sign-off, which can the agent action autonomously? Different per department.
4. Cultural posture — would the agents be presented as tools the department owns, or as standardised utilities provided by a central group?

These are questions any first deployment would naturally surface.

If a conversation continues Notes on how a working conversation could continue through Class NK's existing patterns.