Agents can finally stop waiting for their software to catch up

A weekly briefing to close the gap between what AI can do for your business and what you're (probably) using it for now.

Every week brings the same handful of tasks back around. Appraisal notes that need turning into a clean prep pack. Open-home comments to summarise before Monday. The vendor report that pulls from portals, emails, phone calls, and half a dozen loose notes. The CRM clean-up that always waits for a quiet hour that never quite arrives. None of it is hard because it is intellectually complex. It is hard because it is scattered across too many places, and pulling it together is the part that eats your time.

The first wave of agent AI was about words. Rewrite this listing, draft this email, polish this update. That still matters and it is not going anywhere, but it is no longer where the advantage sits. The more interesting shift is that AI is starting to help people who have never written a line of code turn repeated work into small, supervised tools. The next edge is not better prompting. It is having the routine parts of your week run as a defined workflow instead of starting from a blank page every time.

The signal

On 2 June 2026, OpenAI reported that Codex, its coding tool, is now being used well beyond software development. About a fifth of its users are knowledge workers rather than developers, and that group is growing three times faster, leaning on it for reports, spreadsheets, presentations, contracts, research, data analysis, and the kind of lightweight tools that used to need an engineer. A companion release the same day went further, adding role-specific versions for analysts, marketers, salespeople and others, built around the apps those teams already use.

Anthropic is heading the same way with Claude Cowork, a desktop product aimed at knowledge work that sits across your local files, folders, and everyday apps, with the best fit being the high-effort, repeatable jobs.

The detail that matters for real estate is not "learn to code" and it is not "let AI run your agency". It is that software is starting to shape itself around the operator, instead of forcing the operator to shape themselves around the software.

Why this matters in real estate

Most real estate software was built for a broad market, which does not make it bad but does make it blunt. A CRM holds your contacts without telling you who needs a call today. A vendor reporting tool produces the report and still leaves you stitching the story together. A head-office platform can have the right intent and still feel slow to change, or just slightly wrong for the way you actually work.

That gap is what AI is starting to open up. You can now look at building something that fits your own workflow rather than waiting for a vendor roadmap or a head-office product cycle to get to it, which, realistically, it never will. That does not mean ripping out your core systems. It means building around them. A small internal tool might prepare an appraisal pack, sort open-home feedback, assemble a vendor update, give a listing a once-over before it goes live, clean a CRM segment, or turn messy campaign notes into a next-action list.

The point is not a pile of half-finished software. It is one disciplined experiment at a time. Pick a task that comes back every week, define what goes in and what should come out, decide what a human has to check, and test it on safe data before it touches anything live.

The old software gap is narrowing

For years, an agent without a big software budget had to take whatever was on offer and build workarounds on top: a spreadsheet here, a saved search there, copy-paste routines, notes apps, email folders, and a fair bit of memory. AI changes the economics of that. You still need judgement, process, and a review step, but the distance between "this annoys me every week" and "I can test a better way to do it" has got a lot shorter.

That helps the independent operator and the smaller business most obviously, but it is just as useful inside a large group. Having a platform does not mean every job is solved. The platform might handle the database, the compliance, and the reporting while you still need a better way to prepare, summarise, compare, brief, follow up, or review. The advantage was never having no systems. It is being close enough to the work to know exactly where the system lets you down, and that is where you start.

Build with discipline

A word of caution, because this is where it tends to go wrong. This is not licence to build software for the sake of it, to feed private client data into an untested tool, or to wire AI into your live CRM, email, contract, or financial systems before you understand the workflow and have reviewed it. The better path is slower. Start with something repeated, valuable, and currently messy. Use fake data, anonymised notes, or a low-risk example. Write the workflow down before you automate any of it. Keep the first version small enough that you can actually inspect what it produces, and treat that output the way you would treat work from a new assistant: useful, but not trusted until you have checked it.

The question is not "can I build a tool". It is "can I describe the job clearly enough that a tool would help".

The audit to run this week

Pick one repeated task. Not your whole business, not your entire CRM, not "automate prospecting". One task. Then answer seven questions about it:

What starts the task?
What information goes in?
What should come out?
Who uses the output?
What has to be checked by a human?
What data should stay out of it for now?
How would you know the new way was actually better?

If you cannot answer those, you do not have a tool brief yet. You have a vague wish to automate something, which is a perfectly fine place to start. The prompt below turns the wish into something concrete.

Use AI to define the tool before you build it

This is where AI earns its keep before a single tool exists, working as a structured thinking partner rather than a developer or a stand-in operations manager. Most agents have never written their workflows down. They live as habits, notes, templates, inbox searches, browser tabs, and memory. The prompt below takes one repeated task and decides whether it is worth structuring. If it is, it hands you two things: a starter prompt you can run the same day, and where the task is genuinely tool-ready, a plain-language build brief that describes the workflow clearly enough to give to an AI assistant or a builder. It will not write the software for you. It will define the job clearly enough that you, or a tool, could build it.

Run it on something low-risk first. Use fake data, old anonymised notes, or a simple example, and keep real client data out of it until the workflow is tested and the review step is clear. Paste this into ChatGPT, Claude, or Gemini:

PromptAgency workflow tool audit

You help a New Zealand real estate agent decide whether one repeated agency task is suitable for a small supervised AI-assisted tool, and if it is, you write the starter prompt for them.

This is not a software build request. Do not write application code. Do not recommend connecting to live CRM, email, contract, financial, or client-data systems. Your job is to help me define the workflow clearly enough to decide whether it deserves a small tool, a reusable prompt, a checklist, a spreadsheet, or a simple process change, and then to hand me the first version if a reusable prompt is the right step.

Ask me one question at a time, including the four starting questions below. Keep each question short. Wait for my answer before asking the next.

Do not ask a question if I have already answered it directly or indirectly. Use my previous answers to infer what is already known. If an answer is partial, ask the next most useful follow-up. If an answer is vague or generic, especially about the inputs, what makes the task slow or inconsistent, or what a human must check, ask a sharpening follow-up before moving on. If I answer the question about what makes the task slow or inconsistent with something like "it just takes ages", do not accept it. Ask me where the time actually goes and what varies between attempts, and keep asking until you have a specific answer. Do not produce the brief until you have one. Do not accept thin answers on those three points, because the quality of the brief depends on them.

Examples of the kind of task an agent might bring you: turning appraisal notes into a prep pack, assembling a weekly vendor report, or sorting open-home feedback into themes. Use these only as reference for the level of detail to gather. Do not assume my task is one of them.

Gather enough information to understand:

- the repeated task
- how often it happens
- what starts the task
- what information goes in
- what output is needed
- who uses the output
- what currently makes the task slow, messy, or inconsistent
- what existing tools or systems are involved
- what the current workaround is
- what must be checked by a human
- what data should not be used yet
- what a useful first version would look like

Start with these questions, asked one at a time:

1. What repeated task do you want to improve?
2. How often does it happen?
3. What tools, files, notes, or systems are involved now?
4. What output do you want at the end?

Then ask the missing questions needed to complete the audit.

Once you have enough information, produce a practical tool brief, no longer than roughly one page for sections 1 to 8, with these sections. Every brief must show all ten section headings, in order, every time. Where a rule below says a section is not completed, keep the heading and explain why in one line. Never silently omit a section.

1. Workflow summary.
State the repeated task, trigger, inputs, current tools, current workaround, output, and user.

2. Suitability.
Classify the task into one of four buckets:
- Ready to try: the inputs are consistent, the output is specific and checkable, and the risk of a wrong output is low or contained. A reusable prompt or small tool will save real time.
- Better as a prompt or checklist first: the workflow is sound but the time saving does not justify a tool yet. A saved prompt or a written checklist is the right size.
- Needs a tidy-up first: the inputs are unclear, ownership is uncertain, or the output varies too much to automate reliably. Sort the process first.
- Not yet: the task involves high-risk data, unclear human review, live connected systems, or an action that directly affects a client, vendor, or buyer. Do not automate this yet.

Before you classify, check how often the task really happens. If it is genuinely a one-off rather than recurring, say so plainly: a one-off does not need a reusable tool or a saved prompt. Skip the four buckets, set the section 8 recommendation to "Do it once with a guided prompt", give that prompt in section 9 framed as a single use rather than something to save, and mark section 10 as not needed.

If the verdict is "Not yet", complete sections 1 and 2 in full. State plainly why, and what would have to change before it is worth revisiting. For sections 3 to 10, keep each heading and write one line: not completed because the classification is Not yet. Do not spec a tool you have just advised against.

3. First version.
Describe the smallest useful version of the workflow. Keep it practical. It may be a reusable prompt, a spreadsheet, a checklist, a form, a template, or a tiny internal tool.

4. Inputs and outputs.
Create a table with:

Input | Source | Safe to use in first test? | Notes

Then create a second table with:

Output | Who uses it | Human review required | Notes

5. Human review points.
List what must be checked before the output is used with a client, vendor, buyer, or team member.

6. Data boundaries.
List what data should be excluded from the first test. Assume the first test should use fake data, anonymised data, or low-risk examples unless I say otherwise. Flag any NZ Privacy Act 2020 or client-confidentiality considerations specific to handling vendor, buyer, or contact data.

7. Failure risks.
List the main ways this workflow could go wrong, including wrong facts, missing context, weak judgement, privacy risk, over-automation, or a tool that creates more admin than it removes.

8. Recommended next action.
Give one clear recommendation, in plain words:
- Save a reusable prompt.
- Write a checklist.
- Set up a simple spreadsheet.
- Run a small test with fake data.
- Tidy the process first.
- Not yet.

9. Your starter prompt.
Only complete this section if your section 2 classification was "Ready to try", or your section 8 recommendation is "Save a reusable prompt" or "Run a small test with fake data". Otherwise keep the heading and write one line: not needed for this recommendation, because of the classification above.

If it applies, do not stop at the advice. Write the actual starter prompt for my specific task, ready for me to copy. Begin with one plain sentence explaining what it is: a saved instruction I paste in each time this task comes up, so I am not starting from a blank page. Then give the prompt itself, written so that:

- it is built around my task, using the details I gave you
- it states the role and the job in plain words
- it tells me what to paste in each time (my raw inputs)
- it describes the output I want, in the format I asked for
- it builds in the human review step from section 5 and the data boundaries from section 6, including any NZ Privacy Act 2020 note
- if the workflow involves market, comparable-sales, or neighbourhood commentary, the starter prompt must tell the tool to use only what I paste in, never its own knowledge or training data
- it avoids jargon and hype, and never tells me to connect it to a live system

Keep the starter prompt copy-ready and self-contained. Do not wrap it in extra commentary.

10. Your build brief.
Only complete this section if your section 2 classification was "Ready to try". Otherwise keep the heading and write one line: not needed for this recommendation, because of the classification above.

This is the step up from the starter prompt. The prompt in section 9 lets me run the task by hand the same day. This build brief is the written description I hand to an AI assistant or a low-code builder so it has the shape of the tool before any of it is built. It is not code, and it is not a licence to connect anything live.

Begin with one plain sentence explaining what it is: a plain-language spec of the workflow I can give to Claude, ChatGPT, or a builder to scaffold a first version, tested on safe data only. Then give the brief itself, copy-ready and self-contained, covering:

- the tool name and a one-line statement of what it does
- the workflow as numbered steps, in the order they happen
- the inputs: what gets pasted or loaded in each time, and in what format
- the output: the exact format and structure wanted
- the human check points from section 5, written as steps the tool must leave for a person
- the data boundaries from section 6, including any NZ Privacy Act 2020 note, and the instruction to build and test on fake or anonymised data before any real client data
- if the workflow involves market, comparable-sales, or neighbourhood commentary, the instruction that the tool must use only what is pasted in, never its own knowledge or training data
- the instruction that the first version must not connect to any live CRM, email, contract, or financial system

Keep it in plain words. Do not write application code. Do not wrap it in extra commentary.

Every data exclusion you set, in this brief and in any starter prompt or build brief you write, is an absolute rule. Never qualify an exclusion with "where possible", "where practical", or similar wording. If an excluded item turns out to be needed for a step of the workflow, say the workflow cannot proceed to that step until the data question is resolved. Do not soften the rule to keep the workflow moving.

Keep the whole output practical. Use NZ English. Do not use AI hype. Do not tell me to become a developer. Do not claim the tool will work until it has been tested. If something is unknown, mark it as unknown and explain what decision it blocks.

What you get back is not a finished system. It is a clearer brief, a starter prompt you can run the same day, and where the task is ready for it, a build brief that describes the tool clearly enough to scaffold. If the task is worth improving, you will know what the first version should look like and have the spec to build it. If it is not ready, you will know what needs tidying before you waste a weekend building the wrong thing.

The real signal

The edge is moving from better words to better systems. That does not mean you need software. It means knowing which parts of your week are repeated, valuable, and messy enough to be worth structuring, and being willing to build around the way your work actually happens rather than bending it to fit whatever software you were handed. Start with one task this week. Next week, we will take that one step further and build the first version of a small working tool.

That is how we'll help you turn AI into genuine leverage instead of just another tab open in your browser.

— The Listing Signal