An architecture for Wiseway's first two AI assistants — the Knowledge Assistant and the Sales Quoting Assistant — that delivers fast value today and is unlikely to need rebuilding as the AI industry evolves.
Rather than picking a single vendor — Microsoft, Databricks, Snowflake — and accepting whatever they offer, we build on the open standards the AI industry agreed upon in late 2025. Five small components, each replaceable, together delivering one coherent platform. Click any card to see what it does.
Click any box to see what it does, in plain English. The shape repeats for every future agent — Customer Service, AP, AR, Reporting — so you scale by writing new playbooks on the same foundation, not by adding new platforms.
Two agents, one foundation. The Knowledge Assistant proves the architecture is real; the Sales Quoting Assistant proves it is commercially valuable. Both reuse the same connectors, the same identity flow, the same audit trail.
Staff ask HR or SOP questions in Teams, by email, or on the web. The assistant retrieves the right policies from SharePoint, answers in plain English, and cites the source document.
The safety property that matters: the assistant only ever sees documents the person asking is already entitled to see. If you remove someone from a permissions group on Monday, they immediately stop getting answers from documents they no longer have rights to.
An RFQ arrives. The agent reads it, looks up current rates and surcharges from a governed rate-card store, applies client-specific terms, and drafts a quote in your branded format.
The rep always sends. Below-margin quotes are flagged for manager approval in Teams. Every rate used and every approval is logged with full audit trail — the SHEIN-style wrong-rate scenario is prevented by design, not by good intentions.
Conventional AI assistants build a "vector database" — they chop every document into chunks, compute mathematical embeddings, and store them in a parallel system that must be kept in sync with SharePoint. It works, but it adds an indexing pipeline, a permission-replication problem, and a moving part that can drift out of date.
Anthropic's official guidance for the Claude Agent SDK is the opposite approach, called agentic search: instead of pre-building an index, the agent reasons about what to look for, calls SharePoint's own search, reads the most relevant documents, and iterates if it didn't find what it needed. From their own documentation: "We suggest starting with agentic search, and only adding semantic search if you need faster results or more variations."
For Wiseway this means a much simpler pilot: no embedding pipeline, no chunk store, no re-indexing job. SharePoint already has a strong built-in search engine (BM25 with security-trimming), accessible through Microsoft Graph. The MCP connector wraps that search and exposes it to Claude, which then asks the kinds of follow-up questions a real person would.
User asks: "How many days of carer's leave am I entitled to?" → Agent rewrites it as a SharePoint search ("carer's leave entitlement AU staff") → SharePoint returns the top three matching documents the user is allowed to see → Agent reads them → If the answer is clear, it answers and cites the source. If not, it tries a different search. Same loop a thoughtful staff member would run themselves — just faster.
We can layer a vector index on top later if measurement shows the agent is missing genuinely-semantic queries. For the pilot, we don't need it.
In the last eighteen months the AI industry has agreed on a small set of open standards — the way it once agreed on Wi-Fi, SQL, and HTTP. The most important one was donated to the Linux Foundation in December 2025, and is now backed by every major AI lab and cloud provider. History tells us that when this kind of consolidation happens, the open standard wins the long run, and proprietary platforms eventually rebuild around it.
Two practical decisions to work through with Wiseway in the first week — neither is a blocker, but the answers shape the very first deployment.
The Sales Quoting Assistant needs a governed database for rates, surcharges, client terms, and quote events. Most likely this is a PostgreSQL store, and there are two credible places to host it:
Azure Database for PostgreSQL Flexible Server (Australia East) — runs on Wiseway's existing Microsoft Azure footprint, single-bill on the existing EA, sovereign Australian region, mature governance features (pgAudit for who-changed-what, Row-Level Security, versioned history). Strong default.
Neon — an open-source PostgreSQL (Apache 2.0) acquired by Databricks in May 2025. Excellent at branching (git-style copies of the database) which is useful for safely testing rate-card migrations. Hosted on AWS Sydney; Azure regions are being deprecated. A good supplementary tool, less ideal as the primary store for Wiseway because it adds a vendor relationship outside the Microsoft estate.
What we need from Wiseway: where rate cards live today (spreadsheets, an existing app, ad-hoc?), who currently maintains them, and the rough volume of rate changes per week. From there we recommend the right shape — Azure Flex is the likely answer, with Neon optionally added later for safe migration testing.
The pilot needs one realistic HR library to prove the agent's permission-trimming and answer quality. We'd want a brief walkthrough of how HR content is organised today, which jurisdictions (AU, NZ, US, UK) have separate document sets, and which permission groups define who can see what.
From there we configure a single Microsoft Entra app registration with least-privilege access (Sites.Selected) to that one library — and expand permissions as confidence grows.