I asked my personal agent
to build an accounting agent.
The enterprise still
needed me.

“What is still open on the close checklist?” It is a small question with institutional weight. A controller needs the right period, the right tasks, the right owners, and the right statuses. A blocked subledger is an exception someone must resolve. It is not a sentence an assistant should improvise.

Month-end close brings together ledger completeness, reconciliations, reporting definitions, review, and sign-off. An assistant can surface evidence and help a team investigate. The authority to post a journal, resolve a reconciliation, or certify the close belongs to a different control process. My experiment began on the read side of that boundary.

I had sample finance files in a Databricks workspace and a personal agent, Muse, with computer use. I asked it to build the Databricks side: load the data, make the finance logic explicit, configure Genie, expose narrow tools, and bring up an application. Later, Codex built a separate client outside Databricks. I directed both builds and reviewed the results.

The question grew from “Can an agent build this?” into an operating question: how should personal agents, enterprise platforms, external reasoning systems, and humans work together when the answer has to survive scrutiny?

The runbook records a build through the Databricks browser: a Unity Catalog schema and volume, uploads, notebook execution, managed Delta tables, curated views, control tables, SQL functions, a Genie space, and eventually a deployed Databricks App. Muse used the platform surfaces a person would use. That made the work visible at each step: files could be listed, tables counted, function outputs inspected, and errors opened.

Computer use expanded what my personal agent could do without requiring me to hand-build a bespoke adapter for every setup screen. It also inherited the friction of real interfaces and real permissions. The custom serving path encountered signature validation, a stopped SQL warehouse, and serverless authentication problems. The initial runbook honestly left that endpoint unverified.

The app story moved forward separately. The October 4 update records month-end-close-app running, with Close Status, Outstanding Reconciliations, Variance Review, and Ask the Assistant returning data. That later evidence supersedes the earlier “app not built” entry; it does not retroactively prove the custom serving endpoint.

I supplied direction, chose the scope, controlled credentials, and decided what counted as success. The agents performed substantial implementation and diagnostic work. That division is the point: useful delegation can increase capacity while keeping consequential judgments with an accountable person.

The direction is already public. Meta’s September 28 enterprise announcement names the Muse agent, Meta Business Agent, Muse API, and Muse Code among the technologies it plans to bring to businesses and developers. That makes this experiment relevant to an approaching operating model: an employee delegates platform configuration and application development to an agent that can work across existing enterprise tools.

The demonstrated capability is concrete. Muse can operate a browser, inspect configuration, run notebook code, read errors, and work toward a deployed application. The enterprise version would assign it a platform-building task with a specific workspace, data classification, time budget, and change boundary. Its access would come from an approved identity and session, with credentials brokered by the organization rather than copied into a prompt.

I would start it in a development workspace using synthetic or approved test data. A task might be: create an accounting data product, configure a curated Genie space, implement the required read functions, and prepare an app. Muse could do the setup through computer use, and use approved SDK, CLI, or infrastructure interfaces where those give more reproducible results. Screens are useful for discovery and diagnosis; configuration-as-code and versioned source are better artifacts for repeatable release.

The handoff is a reviewable change package: notebook and app source, resource configuration, required grants, control-query results, test evidence, and a rollback plan. A finance owner reviews the definitions. A platform owner reviews access, compute, and deployment. CI verifies the artifacts before an approved release identity promotes them. The build agent should not be able to grant itself production access or approve its own permission changes.

This also keeps two principals separate. Muse’s delegated build identity may configure a development resource; the deployed accounting app receives its own runtime identity and read grants. Revoking the builder should not disable the app, and a compromised app should not inherit the builder’s configuration privileges. For a browser-based enterprise session, scope, session expiry, destination controls, and retained activity evidence all need explicit design.

Meta describes Muse’s dedicated computer and user control in its personal-agent announcement. The release gates, enterprise identity controls, and separation of duties above are my proposed deployment pattern. This demo does not verify that those controls are available in a particular Muse enterprise product today.

The two transaction tables contained 110,485 and 40,059 rows: 150,544 rows across the pair. I do not treat that sum as 150,544 distinct transactions; the build record does not establish that the samples are disjoint. Reference tables supplied chart of accounts, statement mapping, calendar, organization, departments, and scenarios.

Above that layer, the build made three finance views explicit: trial balance, actual-versus-budget P&L, and top variances. It also added the close checklist and reconciliation controls. These definitions made the questions executable and inspectable before natural language entered the picture.

The source data forced decisions. Budget coverage was sparse, so the useful variance story became month-over-month actual movement. That is a change in business meaning: an actual-versus-budget exception and a change from a prior month answer different questions. Calling both “variance” without explaining the basis would give the assistant an easy way to sound precise while misleading the reader.

Other details were smaller but equally revealing. Line Item became Line_Item to satisfy table naming constraints. Signage was treated as a numeric multiplier. “Profiit Before Tax” and “Ammortisation” remained source labels rather than silently corrected claims. A model could help notice these details; a finance owner still has to approve their interpretation.

The useful combination was the data platform and the agent platform around it. I could start with files, make managed Delta tables, express accounting logic in views, attach permissions in Unity Catalog, and give Genie approved sources. The accounting application and the external client could then reuse those assets. Each new experience did not need a new copy of the ledger and a second set of finance calculations.

Unity Catalog supplies the access boundary. Catalog and schema permissions, table reads, and function execution are evaluated for the identity making the request. In a properly configured enterprise, row filters and column masks can further restrict what that identity sees. A finance team’s application can therefore reuse a governed data product while retaining a distinct grant from another department’s application. The permission incident in this build showed why that distinction matters in practice.

Computation stays close to the finance data. SQL views and functions express deterministic calculations where the tables live; Genie translates broader questions over curated sources into analytical work. The external app receives bounded results for a question rather than loading the entire ledger into an LLM context. Data that does leave the platform still needs classification, retention, and model-provider policy; a governed query does not make its returned records free to redistribute.

The same capability has several consumption paths. Databricks Apps gives a native application surface. SQL connectors and the Statement Execution API serve structured application queries. Genie serves natural-language analytics, and managed MCP exposes supported capabilities to agent clients. The UI, programming language, and model vendor can change while the approved finance definitions remain shared.

The platform makes the engineering inspectable. Source tables, query results, grants, app status, and failures have concrete places to inspect. An enterprise can add lineage, query history, and audit records to its evidence process. Correlating them into a complete accounting decision trail still requires engineering; the local demo’s runbook and tests are a smaller evidence layer.

That combination makes Databricks one of my strong choices for governed accounting agents. The decision still depends on existing data gravity, cloud and region, identity requirements, cost, latency, and operating skills. Managed MCP remains a preview capability in the documentation we used; enterprise adoption needs a supported-interface and change-management decision, not an assumption that a demo connection is a production contract.

The blueprint below puts the platform choice into an operating structure. The center is the governed accounting capability; the left is the engineering work that creates it, and the right is the set of applications allowed to consume it. Human review crosses all three. Proposed enterprise release controls are drawn separately from the runtime path demonstrated here.

The two builds had different jobs. Muse constructed the platform-side capability through computer use. Codex wrote the external application. At runtime, Azure OpenAI classifies broader requests, the Python backend validates and executes calls, and Databricks serves governed results. Genie supplies the broader finance answer; the external model does not add another layer of financial synthesis.

There is cooperation at build time and at runtime, but no shared autonomous swarm behind the scenes. The human coordinates the builders. The runtime client uses explicit tool contracts. The backend owns execution, and Databricks evaluates access under the caller’s identity. Those distinctions keep “multi-agent” meaningful.

The most revealing incident arrived after deployment. The app’s Ask tab failed with a “Tables missing” permission error. The app service principal had catalog and schema access and function execution grants, but it lacked row-read access to the eight source tables configured for Genie.

Muse took the failure back into the Databricks Genie surface and opened the failed request. The platform exposed the missing access requirement: SELECT on the data assets, alongside USE CATALOG and USE SCHEMA. The runbook records eight table-specific SELECT grants, after which that permission failure was resolved.

This is a concrete multi-platform diagnostic loop. My personal agent was operating the enterprise app, a platform-native agent surface supplied evidence about the failure, and the human-directed build applied the targeted correction. It did not require one vendor’s agent to own the whole ecosystem.

A second error remained. The app parser did not recognize MessageStatus.COMPLETED and misclassified a finished response. Fixing access made completion possible; fixing status handling made that completion visible. One green infrastructure status would have missed both layers.

Once the Databricks App worked, I wanted a separate client to exercise the same finance capabilities. Codex built AI-Staff-Accountant: a small Streamlit application with a shared Python backend and a command-line test harness. It connects directly to the managed Genie and Unity Catalog function endpoints, rather than scraping the first app’s answer.

The simplest design won. The three exact finance questions do not need a general agent loop. They go straight to the appropriate function, and the backend formats the returned records. Azure classifies paraphrases and broader questions, rewrites follow-ups using local history, and lets the backend invoke Genie. That division reduces both cost and opportunities for unsupported synthesis.

This is multi-vendor reasoning grounded in enterprise capabilities, with a precise qualification: Azure interprets intent; Databricks functions return exact data; Genie supplies broader analytical text. We do not ask the external model to reinvent the accounting result. More model participation is not automatically more assurance.

The external PAT and the Databricks App service principal are different authority paths. Identical endpoints or answers do not imply identical permissions. The current client is a local demonstration with a PAT owned by the operator. Enterprise adoption would need managed workload or delegated user identity, not a published service sharing my token.

Any application can be a client. Every client needs a grant.

A React portal, a Python service, a BI tool, an ERP extension, or an agent runtime can consume Databricks through a supported interface. Its backend authenticates, requests a permitted operation, and receives the result under that identity’s policies. The front end does not need a workspace token, and placing a model between the user and the backend does not widen the grant.

Choose the connection for the task. A structured reporting app uses parameterized SQL against approved views through a connector or Statement Execution API. An agent calling a named finance function uses a managed MCP client. A natural-language experience uses a curated Genie capability. A Databricks App can use its dedicated application principal or configured user authorization. These are explicit architectural choices; the accounting client in this repository deliberately implements only its two fixed MCP endpoints.

For a shared background job, a scoped service principal with OAuth machine-to-machine authentication supplies application authority. For a user-specific experience, supported OAuth user/delegation flows preserve the user’s access; Databricks Apps documents on-behalf-of-user authorization and scopes for that purpose. A service-principal request sees the service principal’s grant, so it cannot claim to enforce a narrower user policy unless the application has designed and verified that boundary.

The updated runbook reports that the Databricks App and the independent external client returned matching checklist, reconciliation, and variance results. The external screenshots support the important reuse story: a second application reaches the governed capabilities through its own connection path.

Our current automated check makes a narrower distinction. Checklist and reconciliations match the build spec. The variance function returns four rows, but their labels differ from the spec’s expected rows. The runbook’s external variance screenshot shows the same line items we observed live. That is agreement between observed paths and a disagreement with the written expectation.

The correct response is to keep the acceptance failure. Changing the display to invent the expected rows would destroy the point of grounded reasoning. Revising the expectation without a finance owner’s review would hide the question of which business definition was intended.

Even perfect cross-application agreement would not independently validate accounting semantics: both consumers can share the same underlying view and therefore the same defect. The second path tests interoperability and consistency. Control SQL, source inspection, and domain review still have separate jobs.

The architectural opportunity is broader than finance chat. Enterprises already have business platforms, identity, policy, data products, and human review. Personal agents can help build and operate those systems. Platform agents can expose domain context. External agents can serve different users and reasoning needs. The integration should preserve the ownership of each responsibility.

For a controller, that means calculation definitions, cutoff, reconciliation completeness, preparer/reviewer roles, and escalation remain explicit. For a platform owner, it means a permission change must be reviewed for its purpose and breadth. For an AI engineer, it means routing, schema validation, timeouts, unsupported answers, and provenance are normal software contracts rather than promises in a prompt.

My human involvement here was active supervision, not a production approval system. The app contains no journal-posting or close-signoff path, no enforced segregation of duties, and no immutable approval ledger. The next enterprise version would have to make those controls executable before it gained write authority.

“Enterprise grade” is therefore the design direction: governed data, bounded capabilities, visible errors, separate identities, and reviewable evidence. This Free Edition experiment demonstrates parts of that pattern. It does not establish production reliability, compliance, financial correctness, or autonomous close.