Our previous posts looked at trade affirmations, reconciliations and Agent Workspaces: the workflows we build for clients and the thinking behind them. We believe that rethinking how our clients work requires the same willingness to experiment inside Yantra. That extends beyond software development to the recurring work that keeps the company running.
We have been developing agents across finance, project management and compliance. Some now handle substantial preparation in the background. Others proved too broad and were replaced or discarded. In this post, we share what we learned from both outcomes across finance and operations.
Test early, and be willing to stop
Our first principle is to test opportunities for automation even when the feasibility is uncertain. If a process feels repetitive or awkward, we favour trying a prototype over assuming it cannot be automated. Prototyping is quick enough to reveal whether a fuller build deserves the investment. Our finance workflows started this way: we did not know whether an agent could reliably collect invoices, interpret them and prepare correct accounting records.
Our second principle is to stop when an approach does not justify its upkeep. An agent creates work as well as completing it: instructions need updating, connectors need maintenance, and exceptions need investigation. Time already spent building it is not a reason to continue. Sometimes a narrower scope makes the difference; sometimes the right decision is to discard it.
Each experiment still needs a clear process, accessible inputs, defined outcomes and limits on valid actions. Early runs require close supervision. As results become consistent, we shift towards reviewing prepared outputs and exceptions, while retaining the required approvals. Finance earned that continued investment. Our original PM design did not.
Finance: establish the records, then reuse them
Our finance agents now prepare supplier bills and customer invoice drafts, maintain recurring accounting adjustments, and support asset records and reporting. These workflows share much of the same evidence. A laptop invoice supports the purchase record and the asset register, which feeds depreciation and reporting. A customer contract becomes a reusable datasheet of billing terms for subsequent invoices. Making those records available across workflows lets us expand the work without repeating the collection exercise for every task.
The inputs remain spread across Gmail, supplier portals, Xero and Revolut. We use a pull model: Xero holds the accounting records, and agents retrieve additional information from connected systems during each run. Gmail tools collect documents and prepare correspondence. Our Xero MCP connector handles accounting operations, while the Revolut MCP checks completed transactions. Authenticated browser sessions cover supplier portals, and browser control also supports verification in Xero’s interface. We do not maintain a separate finance database.
For accounts payable, the agent reads the original invoice, checks the supplier, currency, coding and VAT treatment, checks for duplicates, and prepares the Xero bill with its PDF attached. It authorises the bill only when the required checks pass; missing documents or uncertain treatment are flagged. For receivables, it uses the contract’s billing terms to generate invoices and prepare Gmail drafts for review. The same accounting records support journals, depreciation and weekly or monthly reports.
Getting this coverage required extending our in-house Xero connector. An operation being available through Xero’s API did not mean our agent could use it; we had to expose it, test the workflow and revise it. During supervised runs, agents also helped document the procedures and identify inconsistencies. We refined these into successive skill versions, so recurring steps and required checks were recorded rather than left to improvisation.
We still spot-check bills and reconcile them manually in Xero. We review and send client correspondence, with further checks during quarterly VAT preparation and annual accounts. The gain is less collection and context switching between those reviews. The main lesson is that several useful automations can grow from the same checked records, provided the agent can reach the evidence behind them.
Project management: maintain the current state
Our PM automation now has two distinct roles. Agents scoped to individual engagements compare Linear, GitHub and meeting records with agreed milestones, prepare progress updates and flag delays. Separately, several team members use a personal “second brain” to maintain their commitments on a Kanban board. Both depend on keeping a current record of the work.
The second brain reviews new meeting records, Slack conversations and email against the existing board. A small promise buried in a DM becomes a tracked commitment; later evidence can update it or show that it is complete. The board carries that state into the next run, along with our corrections to priorities and interpretation. Each day’s activity updates an existing picture of the work, so an unfinished commitment remains visible after the original conversation has disappeared from attention.
That is a more manageable remit than our first design. We initially wanted one PM persona to understand the whole project estate and continually adjust its plans. Some requirements changed during client calls or in-person discussions that it could not access. Keeping the agent informed became a project of its own, and the upkeep outweighed the benefit. We now use bounded engagement agents; when the scope changes substantially, we can retire one and start another with revised instructions.
People still make major planning decisions and correct missing or inaccurate context. The narrower agents support that work, while the second brain captures much of the original ambition to stop commitments slipping through the cracks.
SOC 2: match the agent’s lifetime to the work
Our SOC 2 work separates audit preparation from ongoing monitoring. Preparation agents collect evidence, organise it against requirements and prepare material for review. Because our infrastructure is defined as code, agents can also inspect implementations and propose technical changes through pull requests. People review the evidence and proposed changes, check their scope and approve the work.
These preparation roles have a natural endpoint. Once the relevant exercise is complete, we can retire them. We have built a separate monitoring agent for the continuing work: gathering current state, tracking evidence renewals and flagging changes that could cause controls to fail. It prepares evidence and proposed resolutions for human review during the observation period and beyond. A useful agent does not need to become a permanent part of operations; its lifetime should follow the job.
What this changes
The practical benefit is background preparation followed by dedicated review. We spend less time collecting documents, reconstructing commitments and assembling evidence, leaving more room for proactive work. There is an upfront investment and ongoing maintenance, with the benefit building over subsequent weeks and months. It has also changed how we approach new initiatives: we identify the inputs and desired outcomes early, then test whether automation deserves further investment.
These workflows give us concrete requirements to carry into product development. Finance shows why agents need access to authoritative records and reusable evidence. Our learnings from PM experiments influenced the memory architecture for our client agents. SOC 2 shows that preparation and continuing supervision can require different agents. This is the same thinking we apply externally: understand the work, give the agent the context it needs, and keep people responsible for the decisions.
If you are interested in Arch, or are exploring how agents could improve your own internal operations, .
We will also share the connectors we have found useful in our public MCP repository.