Built for privacy-gated agent handoffs,
with honest pilot-stage caveats.

If something on this page is unclear or inconsistent with a Data Processing Addendum you have signed with us, the DPA controls. Please email us so we can clarify.

1. What the agent harness is

Practice Sprint's agent harness is a system for running narrow, purpose-built AI agents inside an accounting firm's practice-management workflow. Agents read work that's been assigned to them, produce draft outputs (categorisations, summaries, drafts, suggested task breakdowns), and wait for a human reviewer to approve, edit, or reject those outputs.

Three shape-of-the-thing facts:

• Agents propose. Humans approve. No agent output applies to your data until a reviewer on your team explicitly approves it. No external action (email sent, Xero invoice raised, ATO interaction) happens without a second explicit approval, separately from the first.
• Evidence first. Every agent output is shown alongside the source material that drove it: the paragraph of the document it read, the email thread it summarised, the task description it interpreted. Reviewers can audit decisions rather than trust them.
• Catalogued and versioned. Every agent is a named, versioned thing with a documented purpose, input/output schema, sensitivity classification, and eval history. We don't ship an agent we can't reason about.

2. What we do with your data

Hosting. Your data sits in Australia. Our primary database, auth, and file storage run on Supabase in the ap-southeast-2 (Sydney) region. No part of your data at rest leaves Australia.

Encryption. Data is encrypted at rest (AES-256-GCM for sensitive fields including Xero OAuth tokens and PII mappings; database-level encryption for everything else). Data in transit uses TLS 1.2 or higher.

Inference. When an agent needs to process text using an AI model, the text is sent to a model provider for inference. Today our cloud inference providers are Google (Gemini) for in-app AI features and Anthropic (Claude) for agent-worker runs (BAS Preparer, BAS Review, Excel Template Filler). A local, Ollama-compatible inference option for firms that require model processing inside their own network is in active development and is not yet available during the pilot. We document all inference providers on the sub-processor list (see §8).

No training. Your data is not used to train, fine-tune, or otherwise improve any AI model, ours, or any of our providers'. Where our model providers' default terms would allow training use, we have contractually opted out. This is a hard commitment written into every DPA we sign.

Logging. We log agent inputs and outputs in two places:

• LLM call audit (encrypted): every prompt sent to a model provider and every response received, retained for debugging model behaviour and incident response. These records are retained until a time-based purge is implemented.
• Agent action audit (seven-year retention): a record of every agent run: who requested it, what it produced, which reviewer approved or rejected, when. This is the record your practice can rely on for your own compliance obligations.

Audit data is tenant-isolated. We do not aggregate or analyse across tenants.

3. What we don't do with your data

• We don't sell your data. Not to anyone, not in any form.
• We don't share aggregated “insights” derived from customer data for marketing or for model improvement. This is a common pattern in the SaaS industry that we explicitly don't participate in.
• We don't let third parties access your data except the sub-processors listed in §8 (strictly for the purposes described there).
• We don't use your data to benchmark against other firms' data. Our evaluation datasets use synthetic or explicitly-consented anonymised examples (see §6).

4. What agents will do, and what they won't

Will do today (as of pilot launch)

• BAS Review Agent. Reviews a BAS workpaper for likely GST coding review points. Flags each finding with a rationale, confidence score, and source reference. Requires reviewer approval before findings are applied. No ATO interaction: lodgement remains a separate human step.

Will do within six months (current roadmap)

• Document categoriser. Classifies documents attached to a task (tax documents / receipts / bank statements / financial statements / correspondence / contracts / other) with a confidence score and the text that drove the classification. The classifier is built; we are finishing the review-and-approve workflow before enabling it for firms.
• Task drafter. Generates a first-pass task breakdown from a client brief.
• Client summariser. One-page snapshot of a client file (drawn from your file + Xero data you've connected).
• Deadline reminder composer. Drafts reminder emails for approaching ATO deadlines.
• WIP categoriser. Suggests billable / non-billable / write-off for time entries, per your firm's rules.

Will not do, ever (by design)

• Lodge anything with the ATO on your behalf.
• Send email on your behalf without a separate, explicit reviewer approval of that specific send.
• Create or modify a Xero invoice, credit note, or journal without a separate, explicit reviewer approval of that specific change.
• Make any decision about pricing, write-offs, or client fees without reviewer approval.
• Process or expose TFNs in prompts, logs, or audit records. TFN handling is governed by a separate sanitisation pipeline; see §5.

Will not do during the 2026 pilot phase

• Act autonomously on a schedule without a task being opened by a human.
• Run in the background on client files you have not explicitly attached to a task.
• Train on your data to improve performance (see §2 “No training”).

5. How we handle especially sensitive data

Australian accounting work involves data the Privacy Act 1988 and sectoral regulators treat as especially sensitive: Tax File Numbers, bank details, super fund details, client health information referenced in tax deduction claims, and similar.

• TFNs, bank account numbers, BSBs, and other identified sensitive entities are sanitised out of the document text our AI agents send to a model provider, via a separate AU-hosted PII pipeline. The model sees tokenised placeholders (e.g., [AU_TFN_1]); the original values are kept encrypted in our database and re-inserted only after reviewer approval. The in-app assist features (Magic Import, task extraction) do not run this pipeline. They send the text you type directly to the model provider, so we ask you not to paste sensitive details like TFNs or bank account numbers into them.
• PII mappings are encrypted at rest with a per-row random nonce (AES-256-GCM). A mapping is retained while its task is active and for 180 days after the task is archived, then permanently deleted. The service has this expiry-and-purge mechanism; the archive trigger that starts the 180-day clock is still being wired, so automatic archive-based deletion is not yet operating end-to-end.
• Prompts and model responses are logged (see §2) but TFN-pattern strings are the primary scrub target of that log pipeline. If we ever detect TFN leakage, that is a P0 incident (see §9).

6. How we evaluate agent safety and accuracy

• Per-agent evaluation datasets. Every agent type has a golden dataset of cases with correct outputs and a documented grading rubric. Datasets combine synthetic examples, adversarial traps, and (where the customer has explicitly consented, and after redaction through our PII pipeline) anonymised real examples.
• Four metric families: correctness (did the agent get the answer right?), safety (did the agent respect tenant isolation / approval gates / sensitivity tiers? Scored as pass/fail, never averaged), calibration (does a 70%-confidence output turn out to be correct ~70% of the time?), and efficiency (tokens, latency, cost per run).
• Eval cadence: the suite runs in CI on every pull request that touches agent code, in mock mode by default; real-model runs are tagged explicitly (an[eval-real] label). We review eval results before shipping agent changes. We don't yet enforce deploy-blocking on regressions. Branch protection isn't in place on the repository today, so this is a review discipline, not an automated gate, and we say so honestly.
• We publish eval pass rates to pilot partners. Post-pilot, we intend to publish a public summary on this page.

7. What happens when an agent gets it wrong

Agents get things wrong. Confidently, sometimes. Our architecture assumes this:

• Confidence scores are shown next to every output. Low-confidence items are flagged to the reviewer, not hidden.
• Sensitivity tiers (low / medium / high) are assigned to every agent type. High-sensitivity outputs (anything touching TFN handling, payment instructions, ATO interaction) cannot be auto-applied even by a user with elevated permissions.
• Kill switches. We can revoke the AI-agents capability for a single firm (per-tenant) or across all firms (global). Every agent job re-checks this when it is claimed and fails closed if the capability has been revoked. A per-agent-type switch is on the roadmap, not built yet.
• Rollback. Every agent action is reversible. Approved outputs can be un-approved; applied changes can be rolled back from the audit record. Un-sent emails are never un-sent, which is why send is a separate approval.
• Version pinning. Every agent run records the agent version, the prompt variant (hashed), the model ID, and the evaluation dataset version. If a change in a later version causes regressions in earlier outputs, we can reproduce exactly what produced the earlier output.

8. Sub-processors

We use third-party service providers to deliver the service. These are our current sub-processors:

We give at least 30 days' written notice before adding or substituting a sub-processor.

9. Incidents and notifications

We classify incidents by severity:

• P0, Critical: Active data exposure, cross-tenant leak, regulated-obligation failure, or financial loss. Ack within 2 hours of detection; mitigation within 8 hours. Phone the affected Pilot Lead.
• P1, High: Service impairment affecting most users or a material functional regression. Ack within 4 business hours; mitigation within 1 business day.
• P2, Medium: Service degradation affecting some users. Ack by next business day.
• P3, Low: Cosmetic or minor issue. Addressed in next release.

For any P0 incident affecting Firm Data, we notify the affected Firm within 24 hours (2 hours by phone for P0). For incidents triggering the Notifiable Data Breaches scheme under the Privacy Act 1988, we cooperate with the Firm's OAIC notification (or, if we are the relevant notifier, make our own notification within the statutory timeframe).

We publish a blameless post-mortem for every P0 and P1 incident to the affected Firm within 10 business days.

10. Service status and availability

• Scheduled maintenance: announced in-app at least 48 hours in advance where possible.
• Availability expectation during pilot: we target commercially-reasonable availability during AU business hours. We are not an enterprise-SLA product yet, and we say so honestly. Post-pilot commercial tiers will include a defined SLA.

11. Your rights as a firm

• Data export: any Firm can export all its data in a standards-based format at any time, through the app or by written request (served within 7 days).
• Data deletion: on termination of a pilot or paid agreement, we delete your data within 30 days, subject to the retention rules in §2 for audit records.
• DPA on request: we provide our standard DPA to any prospective customer on request.
• Questions and objections: email us. A human replies. (At pilot scale, the human is the founder.)

12. Your rights as a client of a Practice Sprint firm

If you are a client of an AU firm that uses Practice Sprint:

• Practice Sprint is a data processor. The firm that serves you is the data controller. Your primary privacy relationship is with your firm.
• We do not access your data except when requested by your firm's authorised staff or when necessary to deliver the service they have asked us to deliver.
• For access, correction, or deletion of your personal information, contact your firm first. If that channel fails, contact us and we will cooperate with your firm to respond.
• If you use our Client Portal (a product feature some firms enable), your portal activity is governed by the firm-specific privacy policy your firm presents to you.

13. What we won't commit to (honest caveats)

• Pilot-stage product. We are currently working with our first firm.
• We do not yet hold SOC 2 or ISO 27001 certification. We use SOC 2 controls as a design framework today; we don't claim either attestation until we have it.
• We do not guarantee 99.9% uptime. We're a pilot-stage product. We'll commit to an SLA when we go commercial.
• We do not guarantee AI output correctness. Every output is reviewed by a human at the firm before any external action is taken. Our process is designed to catch more errors before they reach your clients, but it is still a review workflow, not a guarantee.
• Some inference happens off-shore (Google Gemini and Anthropic Claude, both US-region). We sanitise sensitive entities before any prompt leaves the AU environment. A local-LLM option for firms that require model processing inside their own network is in active development and not yet available. We'll expand on-shore cloud inference options as they become technically and economically viable.

14. Contact

• General enquiries and privacy questions: hello@practicesprint.com
• Security issues (including suspected vulnerabilities): security@superstackit.com

We read every email. During the pilot, responses are founder-handled during AU business hours.