A freelance project can become difficult long before anyone refuses to pay. A client asks for another feature in chat. Feedback arrives from a second person. Someone promises to pay after the next revision. Each decision may seem small, but by the time the work is ready, the freelancer has to reconstruct what was included, what changed and what is still owed.
The problem is not always missing information. It is information spread between conversations, agreements, files and invoices, with no dependable connection between them. I built Parius to bring those decisions into one shared workspace and carry useful experience into the next request.
Follow one project from agreement to handoff
In the demonstration project, a freelancer and client agree on a portfolio website. The freelancer publishes the deliverables, price, revision limit and final-file conditions. Both people approve the same version. That version becomes the baseline for the work; another chat message cannot silently change the agreed price.
Later, the client asks for a new feature. Instead of trying to remember every earlier conversation, the freelancer selects Review scope. Parius compares the request with the approved agreement, shows the relevant quotation and prepares a reply. The freelancer reads and edits it before deciding what to send. If the work should change, both people still need to approve a new agreement version.
The same project contains milestones, previews, final files and invoices. A client can inspect a milestone preview before accepting the work. An issued invoice makes the amount requested visible. When a final file has acceptance and payment conditions, its download remains locked until those conditions are satisfied and the freelancer explicitly releases it. Locking the final does not prevent the client from paying.
These parts matter together. A payment receipt without the agreement does not explain what was promised. A completed milestone without its invoice does not tell the freelancer what has been collected. Parius keeps each record distinct while showing how it relates to the rest of the project.
Remember a useful decision, with permission
An approved agreement describes the work, but it does not capture every preference a freelancer develops while working. One useful lesson might be to ask for a separately priced proposal before accepting an extra feature. Another might be to keep client replies concise and end with one concrete next step.
Parius can suggest a lesson after an eligible scope review. The freelancer can confirm it, edit it or dismiss it, and can also enter a lesson manually. Only a confirmed lesson enters the storage queue. Project-specific lessons stay within that project; using a general preference across projects requires an explicit choice.
Walrus Memory provides persistent storage and recall for those lessons. Parius tracks the storage job and only shows Stored on Walrus after completion with a blob reference. A later review recalls relevant lessons from the remote service and checks them against the freelancer's eligible references. The application verifies the returned memory identity, blob and exact lesson text rather than trusting any similar-looking search result.
This is retrieval of confirmed experience, not a claim that Parius trains a new model or continuously monitors every conversation. The person chooses what should be remembered, and the later review shows what it actually used.
What changed in a later review
We stored and directly verified ten distinct project memories on the production Walrus Memory service. Every recorded job returned done, its blob matched the saved application reference, and its owner and namespace matched the expected context. The public storage report records the exact lesson text and references. Check that the repository is public and this branch URL is correct before publishing the article.
The later browser test used a new client request: “Could we add a members-only area where customers sign in? Please explain what we need to decide next.” After the tester reported signing out and back in, Parius recalled five confirmed lessons and cited two. One concerned proposing separately priced extra work. The other asked for one concise paragraph, no emoji and a concrete next step without inventing a price or promising approval.
The comparison produced the same scope conclusion with and without memory: the requested functionality was additional work. The baseline reply used a longer email format with name placeholders and a closing. The memory-enabled reply was one paragraph and ended by asking whether the freelancer should draft the change proposal.
The useful difference was that Parius followed the freelancer's confirmed communication preference. We did not need the model to reverse a correct scope decision to demonstrate learning. Equally, different wording alone would not establish an improvement. The cited preference and the resulting structure explain the specific benefit observed in this example.
The browser evidence summary and a separate fresh-process comparison record these checks. They are separate runs and should not be presented as the same event. A limitation also appeared: one explanation overstated an inference as an explicit exclusion. Checked source quotations do not guarantee every sentence of generated prose is accurate, which is why the advice remains reviewable rather than authoritative.
Verify a payment instead of trusting a message
Payment promises and received money have different meanings. In Parius, a promise reported by the freelancer stays unconfirmed until the client confirms it. It never reduces the invoice balance. A follow-up draft uses saved invoice and promise facts; AI assists the wording, while the person reviews and explicitly sends the final message.
For Sui USDC payments, the client verifies a sending wallet, reviews the exact network, token, recipient and amount, then signs the transfer in their wallet. Tatum supplies the transaction evidence. Parius checks the transfer's success, sender, recipient, canonical asset, amount and time window against the reviewed instructions.
The freelancer then reconciles that verified receipt against the invoice. If the same payment was already entered manually, the matching manual record can be replaced rather than counted twice. Reconciliation records a payment that already happened; it does not send more money. The freelancer separately releases the final file when its conditions are met. In our two-account walkthrough, the client successfully downloaded the final TXT after payment and release.
Walrus Memory uses Mainnet. The invoice and agent payment demonstrations use Sui Testnet and matching Tatum Testnet configuration. These are separate integrations, and deploying the website does not change either network automatically.
Let an agent help with one reviewed payment
Parius also exposes a MCP interface. A short-lived, revocable key gives a compatible AI client access to one project's permitted context. The tools can read the project, inspect a delegated payment handoff and check its status. They cannot read private lessons, send messages, approve terms, reconcile receipts or release final files.
For one explicitly reviewed invoice request, a dedicated local Testnet wallet can complete an MPP payment. The service returns an HTTP 402 challenge bound to the request, sender, amount, recipient, asset and expiry. The local runner previews those details before execution, saves the signed transaction before broadcasting, and returns the payment proof. Parius verifies the transfer through Tatum. The freelancer still handles reconciliation and final release.
A separate live QA run paid 0.01 Testnet USDC, completed verification and reconciliation, and returned the saved result on retry without initiating another transfer. The Sui transaction and acceptance record provide the evidence. This was a separate payment run, not the payment for every screen shown in the website story.
The integration demonstrates bounded agent assistance. It does not give an AI unrestricted access to a person's wallet or permission to make financial commitments based on a client message.
What I want to improve next
The next work is to make the existing journey easier to rely on: clearer next actions around payments, stronger hosted recovery checks, and better visibility into the gap between completed work and invoicing. I also want to evaluate which remembered preferences help across realistic requests and which need correction or exclusion.
Parius does not hold funds in escrow, resolve formal disputes or offer fiat cash-out. Notifications and broader agent capabilities remain roadmap work. Remote memory deletion requires account-owner handling after local exclusion. Those limits are part of describing the product honestly, rather than implying that one shared workspace solves every problem in freelance work.
You can try Parius, read the user documentation, and inspect the repository. The implementation and evidence are there to make the workflow understandable: what was agreed, what the assistant remembered, what was delivered and what was actually paid.
Top comments (0)