From AI experiments to dependable work

A practical guide to choosing, testing and operating useful AI workflows.

Begin with a piece of work

A useful AI experiment can still leave a team with a difficult job. A draft appears quickly, then someone spends the afternoon finding missing context, correcting assumptions and asking whether the information is current. The output looks finished before the work is finished.

That is a useful place to begin. Follow the job from the first request to the person who needs the result. Ask what they are trying to achieve, where time is lost and who takes responsibility when something goes wrong. Then decide whether AI could help.

Our approach is to understand the work, make a practical change and check whether it helped. Advice establishes what is worth trying. Implementation makes the proposed change concrete enough for people to use and examine. Both matter: a sensible recommendation needs a practical path into the work, and a working tool needs a clear purpose.

For leaders in Melbourne companies and government organisations, the starting question can be modest: can we make this recurring job more dependable? You do not need to decide the future of your whole organisation to answer it. You need a useful problem, the people doing the work and someone with the authority to decide what happens next.

What maturity means here

The framework in this guide is an Alongside People discussion framework developed for this guide: Understand → Try → Repeat → Operate → Improve. It is not an official standard, certification or validated assessment. It describes evidence worth establishing for one workflow. It does not rank an organisation or prescribe a universal sequence.

A team might operate one process dependably while still exploring another. A change in tools, information or people may uncover a weakness in previously reliable work. Revisiting an earlier question is reasonable.

Maturity means the people responsible can explain the purpose, boundaries and observed results of the work. They know what AI may do, what a person must decide, how the result is checked and what happens when it fails. More autonomous AI is an option to justify, rather than a required destination. Human approval at every consequential step can be a sound design.

Keep six questions beside the stages: what is the purpose; who owns it; what information is available; what is permitted; how will it be checked; and how will people recover? A useful next step could be better information, clearer responsibilities or ordinary automation. Sometimes it is less AI.

Two fictional workflows

The examples throughout this guide are fictional, constructed to explain decisions. They are not accounts of Alongside People's work, clients, government engagements or observed results.

Fictional company example: A Melbourne service business prepares a weekly delivery brief. Its coordinator gathers agreed project updates and drafts a summary for the operations manager. The manager still needs to find missing facts and distinguish confirmed commitments from suggestions. The proposed experiment is to help prepare a source-linked draft, leaving priorities and commitments with the manager.

Fictional public-sector example: A government communications team drafts a staff reference note from already published service notices. The note must preserve dates, conditions and source links. The proposed experiment concerns factual drafting from authorised public sources. It makes no eligibility assessments, administrative decisions or changes to services. Appropriate internal approval is a prerequisite, not an assumed property of the example.

Neither example predicts a benefit. Each gives us a job to follow and a question to test.

Understand: establish the purpose

Enter this stage with a recurring job, a problem or a proposed use. Follow a representative instance with the people involved. Record the request, inputs, decisions, handoffs and finished result. Ask the recipient what they still have to find out. A process map is useful when it reveals something that could change a decision.

In the fictional company, the manager might need a reliable list of confirmed commitments more than a polished narrative. In the fictional government team, the recipient might need the exact source date and wording of a condition. Those observations would change what the draft should contain before any tool is chosen.

The outcome owner defines good work and identifies decisions that remain human-owned. Record current performance as a baseline: how long the job takes, the effort involved, common corrections and the recipient's experience. Establish what information can be used and who can authorise the experiment.

Exit with a representative process map, named owner, relevant users, information and permission constraints, a baseline and one testable question. The benefit hypothesis is that clearer handoffs or removing unnecessary work may help, even before AI. Our team can help follow the work, identify alternatives and design a bounded experiment. If the problem cannot yet be described or permissions are unresolved, pause the proposed AI use and improve the brief.

Try: make one bounded change

Enter when the owner has agreed the question, permitted information and actions, comparison method and stop conditions. Keep the experiment small enough to inspect. Define what the tool can produce, who checks it and what it cannot do. Choose representative examples, including incomplete, conflicting and awkward inputs.

In the fictional company, the tool drafts from an agreed set of project updates. The manager checks every commitment against its source. It cannot contact customers or change a delivery date. In the fictional public-sector team, a reviewer compares the draft with the published notices, checks their currency and confirms every date and condition. The tool cannot decide which service a person should receive.

The benefit hypothesis is reduced preparation effort while retaining useful quality. A quick draft does not establish that benefit. Record missing facts, unsupported statements, corrections and the time needed to review them. Ask the recipient whether the result serves the purpose.

Exit with documented observations from the agreed examples and the owner's decision to revise, stop or continue. Our team can help design the trial, build a prototype or agreed implementation and make the checks explicit. If sources cannot be traced, errors exceed the agreed limits or checking becomes impractical, return to manual handling. A stopped experiment can still answer a valuable question.

Repeat: make the useful change reproducible

Enter when the trial provides a reason to continue and an operational owner accepts responsibility. Now find out whether the result depends on one person's memory or unusually tidy inputs. Establish consistent instructions, context, permission boundaries and checks. Document exceptions and a manual fallback.

In the fictional company, each update has a source, date and clear indication of what is confirmed. The workflow flags missing information instead of filling gaps with plausible prose. In the fictional government team, the approved source list and review instructions distinguish an unchanged notice from a revised one. If an authoritative source cannot be reached, the draft is held for a person to resolve.

The benefit hypothesis is fewer missing details and less rework across repeated use. Compare the whole job with the baseline over an agreed sample and period. Count setup, review, correction and handoff effort. Describe what the sample does and does not cover; a quiet week cannot establish performance during every difficult situation.

Exit with working instructions, representative checks, exception records, a usable fallback and evidence supporting the owner's acceptance decision. Our team can implement the bounded workflow, document responsibilities and prepare the handover with its users. If different people cannot reproduce useful work or important exceptions remain hidden, keep refining the trial. Do not disguise unreliable repetition by narrowing the definition of success.

Operate: give routine work an owner

Enter when the client authorises routine use in an agreed scope. Name the owner and backup, define access, establish change controls and make failures visible. The team needs to know who can pause the workflow, how to complete the job manually and who handles an unresolved problem.

In the fictional company, the coordinator can recognise a failed run and tell the manager which brief needs manual preparation. The manager remains responsible for priorities and commitments. In the fictional public-sector team, an authorised person approves the reference note through the team's agreed review process. A new information source or changed tool capability triggers review before use expands.

The benefit hypothesis is less chasing and more consistent work. Test it through actual use, including the burden of operating the process. Exercise recovery rather than relying on a paragraph saying that a fallback exists. Can a colleague complete the job when the usual person is away? Can the team explain which version was used?

Exit with operating guidance, ownership and backup, visible exceptions, access and change arrangements, exercised recovery and a review of use. Our team can help connect the information and tools, establish these practices and hand over responsibilities. Ongoing support needs a separate agreement. If ownership disappears, permissions change or recovery fails, reduce scope or pause routine use until the gap is resolved.

Improve: let evidence change the decision

Enter when there is enough routine-use evidence for a useful review. Compare outcomes with the original purpose. Include quality, end-to-end time, cost, review effort, exceptions and the experience of people doing and receiving the work. Check relevant changes in tools, policies, information and the job itself.

In the fictional company, the owner could discover that a structured update form solves more of the problem than generated prose. Reducing AI use could then be the improvement. In the fictional government team, changes in published notices or internal guidance could require new review instructions, a smaller scope or a pause. These are possible decisions, not reported findings.

The benefit hypothesis is that review helps a team retain useful changes and avoid extending disappointing ones. Each review exits with a recorded decision to retain, revise, expand or retire the workflow, its supporting observations and the next review trigger. Our team can help interpret the evidence and implement separately agreed changes.

Any broader delegation needs a fresh question about purpose, authority and checks. It does not inherit approval from an earlier trial. Review should leave someone able to explain the decision, including why the existing level of human involvement is still appropriate.

Count the whole job

Choose one primary outcome before the experiment. It might be end-to-end completion time, avoidable rework or the recipient's ability to act on a brief. Define it clearly enough that people can collect comparable observations. Add checks for quality, review burden, cost and user experience so that improvement in one measure cannot hide a worse result elsewhere.

Keep waiting time separate from active effort. A brief might arrive earlier while requiring more checking. Record software costs alongside setup, training and ongoing work. A benefit that helps one person may move effort to another; ask both. Do not turn every observation into a financial saving or assume spare time becomes reduced expenditure.

Keep the original baseline, example set and acceptance criteria. If conditions change, explain the difference. If observations are sparse, report what was seen and what remains unknown. Anecdotes can help identify the next question; they cannot establish a universal result.

The one-workflow worksheet provides space for this comparison. Its purpose is to support a decision. There is no maturity score, and blanks should reveal missing evidence rather than invite confident guesses.

Check the organisation's rules

For government teams, identify the organisation and use case before applying a policy. Victorian agencies, councils and Commonwealth organisations should not be treated as a single policy audience. Bring the relevant information, privacy, security, records and procurement owners into decisions that need their authority.

For organisations within its scope, the Victorian generative AI administrative guideline requires agency-approved tools to be used ahead of publicly available tools, limits information entered into unapproved tools to public information, and retains personnel responsibility for work quality. Information entered into an approved tool must stay within the protective marking the organisation permits for that tool. Organisation and sector policies may set higher thresholds. Read the guideline and its scope before applying it.

OVIC's enterprise generative AI guidance addresses preparation and continuing privacy and security review for Victorian public-sector organisations. An enterprise product label is not a substitute for that preparation. Companies can also consult the National AI Centre's Essential AI practices as practical guidance.

This framework cannot provide policy approval, legal assurance or procurement eligibility. Use it to prepare a clear proposal for the people authorised to decide. Do not put sensitive material into a tool merely to complete the worksheet.

A useful first move

Choose one recurring workflow. Bring a representative example, invite the person doing it and the person relying on it, and name the owner. Describe what happens now, what should be easier and what must remain dependable. Use the worksheet to record evidence and unknowns.

Our team helps with both advice and hands-on implementation. We can work out where to start, improve one agreed process, or build on a change that has proved useful. The work can leave you with a process map and experiment brief, a working improvement with checks and handover, or operating practices for a coherent system. Scope, delivery arrangements and ongoing responsibilities are agreed for the engagement.

A useful outcome might be a dependable change, a better question or a well-supported decision to stop. Each deserves clear reasoning. Tell us what you're working through.

A first decision you can make together

In the fictional company example, the manager might agree: “We will try source-linked drafts if checking remains manageable, every confirmed commitment can be traced to the original update, and delivery receives fewer missing details.” Record what those limits mean before the trial; this sentence supplies no measured result or universal threshold.

For an agent that can choose further steps, also agree a time and spending limit, the person alerted when work is held, and how to correct an error already distributed. Record the review trigger when a tool, model, source or permission changes. A prompt alone cannot enforce those controls; the operating design and trial need to demonstrate them.

Sources checked 3 October 2026. The linked resources support the specific policy statements; the examples and workflow method are proposed applications, not proof of client outcomes. Recheck applicable requirements before implementation.