Customer record
Customer data, source mappings and definitions brought into a record your team can use.
NTWRK / AI-NATIVE INTELLIGENCE YOU OWN
Quiet intelligence
beats loud platforms.
NTWRK is a Melbourne consultancy that builds intelligence into the systems your business runs. The work starts with a 30-day proof of concept.
30 DAYS · RANK THE USE CASES · TEST ONE · DECIDE WHAT COMES NEXT
Your environment
- Record
- Model
- Agents
- Workflows
Rights and dependencies documented
Rented account
- Record
- Model
- Agents
- Workflows
Pay to access
SELECTED CLIENTS
01 / WHY NOW
The rented model is getting expensive to defend.
For years the trade seemed fair. Customer data went into rented platforms. AI arrived as seats and pilots. Whatever came back was treated as strategy.
It doesn't hold anymore. AI is only as useful as the first-party data underneath it. Risk teams need decisions they can explain. From 10 December 2026, privacy policies must disclose certain automated decisions. Finance asks what remains when the contract ends.
The next advantage isn't another dashboard. It's what your team could still run if a supplier relationship ended.
The old deal
The intelligence you rent was never yours to keep.
Until 2026
The rented default
Customer data in rented platforms. AI bought as seats and pilots.
2026 · Three pressures
- AI needs governed data
- From 10 Dec 2026, privacy policies must disclose certain automated decisions
- Finance asks what remains when the contract ends
After · Two paths
Owned
Your team can inspect, change and keep running it.
Rented
Depends on the supplier relationship.
Build to Keep · Field notes
A useful next read.
Wes Fischer writes about the decisions behind the build: what to keep, what to question and what to test before committing.
You're subscribed to Build to Keep. The next issue will arrive by email. Every issue includes an unsubscribe link.
Check your inbox. We've sent a link to confirm your subscription. Click it to receive Build to Keep.
We couldn't complete your subscription. Please try again in a moment.
Email delivery is stopped for this address.
We haven't sent a confirmation email. If you'd like us to check the delivery status, email hello@ntwrk.com.au from this address.
02 / WHAT WE BUILD
What a working build can include.
The use case determines the build. These are the parts we may need, with the deliverables and dependencies agreed in the scope.
Your environmentEight possible parts
Records & signals
01
02
Signals
The behaviours and events that matter to the decision being tested.
Decisions & workflows
03
04
05
06
Model
Scoring or prediction logic, with the tests and documentation needed to review it.
Decisions
Rules that turn the evidence into a recommended next action.
Workflows
The steps that carry the decision into the tools your team uses.
Agents
AI assigned to a defined task, with agreed permissions, checks and escalation points.
Measurement & handover
07
08
Measurement
A baseline and outcome measures that show whether the work is useful.
Handover
Documentation, runbooks and training for the people responsible for the completed work.
One build · Yours to keep
03 / THE FIRST 30 DAYS
Assess widely. Prove one thing.
We review the decisions worth improving, rank the possible use cases and test one against criteria agreed before the build. At the end of 30 days, you have evidence for the next decision: build, buy, change the process or stop.
The assessment
A record of the current systems, data and working practices relevant to the problem.
The priorities
The use cases assessed, ranked by value, feasibility and risk.
The proof
A working proof of concept, with its test results and known limits.
The recommendation
A decision pack that sets out the evidence and what should happen next.
Stop at day 30 and the four outputs are handed over, documented.
The POC tests an idea on agreed cases. It does not establish production readiness or guarantee a return. It runs in your environment or an agreed, controlled NTWRK workspace. The scope sets out access, deliverables and handover. Any production build is agreed separately.
04 / BUYING COMMITTEE
One build. Five reasons to say yes.
A build like this is rarely one person's decision. The same system has to answer different questions for the CEO, marketing, data, finance and risk.
One build, read five ways. Each seat asks a different question of the same system.
AI in the work, not beside it.
The agents and workflows sit inside the operation, and your team runs them.
An audience that compounds.
Each campaign adds signal to the customer record your team already holds.
ONE BUILDin your environment
No new silo to run.
Records, pipelines, rules and model logic documented enough to inspect and change.
An asset, not a subscription dependency.
The spend turns into records, workflows, logic, documentation and a trained team.
A smaller surface to explain.
The record, decision logic and governance trail sit where your team can inspect them.
05 / FAQ
Questions worth answering first.
What does the 30-day POC give us?
You get an assessment of the current situation, a ranked set of use cases, one working proof of concept and a recommendation on what to do next. Before we build the POC, we agree its test cases and success criteria. A production build is a separate decision, based on what the proof shows.
Do we need perfect data before we start?
No. It takes enough access to assess a useful problem and understand the limits of the data behind it. The first step is to find out what can be tested, what needs fixing and whether a build makes sense. Bring the decision you want to improve and the systems involved.
What happens if we stop after the POC?
You receive the agreed findings, test results, documentation and completed POC artefacts. The scope sets out their format, where the work runs and any remaining dependencies. Stopping after the proof is a valid outcome. The point is to make the next commitment with evidence, including evidence that says stop.
Can our internal team run the finished work?
That is a delivery requirement to agree before the build, covering who will own the work, what access they need and what documentation and training the handover must include. A completed POC may still need further work before production. Ask to see the handover responsibilities in the scope.
START WITH THE DECISION
Bring the decision worth testing.
Start with a 30-minute conversation about the problem, the systems involved and what a useful proof would need to show.
Scope the 30-day POC