Response to Wiseway Logistics — AI Assistants Brief

A vendor-neutral AI platform you can still own in 2036.

Three assistants in the brief. A foundation that quietly extends to the next ten — customer service, AP, AR, reporting, compliance — without rebuilding. Built on open standards so you can swap the model, the harness, or the host when the landscape shifts. And it will shift.

  • Open source agent harness
  • Australian data residency
  • Skills versioned in Git
  • MCP for every integration
  • One platform, not three silos

01 — Approach

Build for the next decade, not the next demo.

The AI tooling market is moving faster than any enterprise procurement cycle. A platform locked to one vendor's bundled product today is a rebuild in 2027. Our recommendation is a small set of open, swappable layers glued together by open standards — so when a better model, a faster harness, or a cheaper host appears, you change one component, not the whole system.

Vendor-neutral by design

The agent harness (Claude Agent SDK) is open source. Skills live in your GitHub. Every integration is a Model Context Protocol (MCP) server — the emerging open standard for tool calls. Replace any layer without rewriting the others.

You own the IP

Skills, prompts, evals, rate-card logic, TMS adapters — all in a Wiseway GitHub repo, code-reviewed, branch-protected. By the end of the engagement your team merges PRs, not raises support tickets.

Data stays in Australia

Harness and MCP servers run in Azure Australia East alongside your existing Microsoft 365 footprint. Documents never leave your tenant. Only model inference traffic egresses, and that endpoint is configurable.

One platform, three assistants (then more)

Knowledge, Quoting and Transport assistants share the same harness, the same identity, the same admin console, the same logs. Adding AP, AR, customer service or reporting later means a new skill — not a new product.

02 — The stack

Four layers. Each one swappable.

The brief asks for a platform that can be extended without rebuilding. We get there by keeping the layers thin and the interfaces open. Click any component in the diagram below to see what it does and what it can be swapped for.

Channels
Email alias Microsoft Teams Web UI
Agent harness
Claude Agent SDK (open source) swap → LangGraph, Mastra, custom
Skills & IP
GitHub (Wiseway-owned) versioned, code-reviewed, branch-protected
Models
Claude Sonnet (primary) Claude Haiku (cheap, fast paths) swap → any frontier model behind the same interface
Integrations
SharePoint MCP TMS MCP CargoWise MCP CRM MCP MCP = open protocol, any client can use them
Host
Azure Australia East data sovereignty, sits next to your M365 tenant

On hosting the agent harness

Anthropic offers a managed-agents capability where the harness itself runs on Anthropic's infrastructure. It's elegant but, as of today, that infrastructure is US-based — which sits awkwardly with your "keep our data in Australia" preference and means your SharePoint and TMS traffic would cross the Pacific on every call.

Our recommendation is to self-host the Claude Agent SDK in Azure Australia East. The SDK is open source and lightweight — a container you run on App Service, Container Apps, or AKS. Anthropic will support the engagement, but the host is yours. If their managed offering lands in Sydney later, migrating is a redeploy, not a rebuild — because the SDK interface is the same.

03 — Architecture

Click any component to see what it does.

This is the picture for all three assistants — and the ones you'll add later. The harness on the left orchestrates skills; skills call MCP servers; MCP servers wrap your real systems. Nothing here is invented for Wiseway — every piece is an open standard or your existing system.

Channels Orchestration Integration (MCP) Your systems Email alias ask@wiseway / quotes@ Microsoft Teams replaces WeChat for transport Web UI internal portal & admin Claude Agent SDK open source · runs in Azure AU East · model-agnostic orchestrates skills · routes tools · enforces guardrails & approvals Skills GitHub Wiseway-owned Models Claude (swap) behind open API SharePoint MCP HR · SOPs · templates TMS MCP read & write jobs CargoWise MCP rates · clients · shipments Rate-card MCP versioned rates & surcharges SharePoint Online existing Wiseway tenant Wiseway TMS self-developed · API access CargoWise operational system of record Rate-card store to be proposed (see scope)

04 — Initial scope

Knowledge first. Quoting second. Then transport.

The brief is pragmatic: pilot small, prove value, expand. We agree. Knowledge Assistant comes first because it has the lowest integration risk (read-only, SharePoint only) and the broadest staff exposure — the fastest way to build internal trust in the platform. Sales Quoting follows once the rate-card model is settled.

01

Knowledge Assistant

Pilot · read-only · low risk
  • SharePoint MCP reads Word docs directly — no separate ingestion pipeline, updates flow through.
  • Permission-aware via Entra ID groups (manager vs staff, AU/NZ/USA/UK).
  • Channels: email alias and Teams bot at launch; web UI as a stretch.
  • Cites every answer with a link back to the source doc. Says "I don't know" when it doesn't.
  • HR document generation (contracts, onboarding packs) from existing Word templates.
02

Sales Quoting Assistant

Drafts only · never auto-sends
  • Email ingestion of RFQs → extracts origin, destination, service, weight, timing.
  • Rate-card MCP applies current rates + fuel/FX/peak/security surcharges + client terms.
  • Surfaces cost, sell, margin, and comparison to past quotes for the same lane.
  • Below-margin quotes routed to manager approval; everything logged to CRM.
  • Includes a proposal for the rate-card store itself (versioning, who-can-change-what).
03

Transport Job Assistant

After phases 1–2 prove the platform
  • Teams channel replaces WeChat for transport requests.
  • Extracts fields from messy chat → creates / amends / cancels TMS jobs.
  • Coordinator approval queue; high-confidence routine jobs flow through later.
  • Audit trail links every TMS change back to the source message.

05 — Before we can give you a timeline

What we need to know about Wiseway's systems.

The brief is clear on outcomes but light on the systems underneath — which is fair, because that's our job to discover. We can't put numbers against the first two use cases until we've answered the questions below. This is a two-week discovery, not a six-month one.

Databases & systems of record

Blocks: Phase 1 & 2 estimate

  • Which databases sit behind the TMS, CargoWise and CRM? Sizes, schemas, and refresh cadence.
  • Are there reporting replicas / data warehouses we should target for read-heavy queries instead of OLTP?
  • What does authenticated API access to the TMS actually look like today — REST, SOAP, internal-only, rate-limited?
  • CargoWise eAdaptor or direct DB access? What's permitted by your CargoWise licence?
  • Where do rate cards live today? Spreadsheets, a system, both?

SharePoint & document landscape

Blocks: Knowledge Assistant scope

  • How are HR policies and divisional SOPs organised — sites, libraries, folders?
  • Permission model: AD groups, SharePoint groups, or per-document? Does it map cleanly to "manager vs staff" and to jurisdiction?
  • Approximate document count and update frequency.
  • Are there any docs that must not be accessible to the assistant (legal, board, M&A)?
  • Templates for generated docs (contracts, onboarding) — are they final or work-in-progress?

Identity & security

Blocks: Go-live security review

  • Entra ID setup: conditional access policies, MFA scope, guest access.
  • Is there an existing pattern for service principals / managed identities accessing SharePoint and the TMS?
  • What is your security review process for new internal tools, and who owns it?
  • Data classification policy — any "Restricted" or "Confidential" tiers that gate the assistant's reach?
  • Audit-log retention requirements (ASX continuous-disclosure context).

Channels & user experience

Blocks: Channel build effort

  • Is Microsoft Teams already deployed for all 300 staff, including AU/NZ/USA/UK?
  • Existing shared mailboxes you'd like the email alias to mirror in tone / routing.
  • Do staff in non-AU regions have any latency or licensing constraints we should account for?

Hosting & networking

Blocks: Deployment plan

  • Existing Azure subscription & landing zone — region, networking, private endpoints?
  • Approved patterns for outbound calls to model APIs (egress controls, allow-lists).
  • Logging & monitoring stack you'd like us to plug into (Sentinel, Log Analytics, Datadog)?

People & governance

Blocks: Adoption & ownership transition

  • Who is the day-1 product owner for the platform on the Wiseway side?
  • Who in HR owns the knowledge corpus once the assistant is live?
  • Who signs off on rate-card changes once the Quoting Assistant uses them?
  • Appetite for an internal "AI working group" we can hand the platform to at end-of-engagement?

How discovery turns into a number

Two weeks. Three workshops (systems, security, users). Output is a fixed-price Statement of Work for Phase 1 (Knowledge), a tight estimate band for Phase 2 (Quoting), and a written architecture decision record you keep — whether you proceed with us or not.

06 — Next steps

A two-week discovery, then a real number.

We'd like to spend a fortnight inside Wiseway's systems and with Wiseway's people, then come back with a fixed-price Phase 1 and an estimate band on Phase 2. No deck-ware. No surprises after sign-off.

  1. Day 1–3. Systems workshop with TMS, CargoWise and SharePoint owners.
  2. Day 4–6. Security & identity workshop. Map data flows against your classification policy.
  3. Day 7–10. Staff interviews — HR, Sales, Transport coordinators. Watch real workflows.
  4. Day 11–14. Architecture decision record, Phase 1 SoW, Phase 2 estimate band.
Book the discovery workshop Liam Wynne · Wynne AI Consulting · Australia