The Solomon AI master plan

The finance team is about to change

Today, finance is organized around delay.

A customer promises to pay. Someone updates a spreadsheet. A vendor sends a contract. Procurement reviews it, then legal, then finance. A bill arrives and waits for approval. The books close weeks after the month ends. The forecast is rebuilt from information that was already stale when someone entered it.

Most work moves in sequence because people have limited time. Legal does not review every possible contract before procurement asks. Finance does not reconcile a payment that has not occurred. A controller cannot inspect every transaction as it happens. The company waits for one person to finish before the next person begins.

Agents remove much of that constraint. They can review the contract, model the cash effect, check the budget, examine the vendor, prepare the accounting treatment, and identify the required approvers at the same time. They can reconcile continuously. They can watch every invoice and every balance without waiting for month-end.

That will change the finance team’s job.

People will spend less time gathering evidence, chasing routine approvals, coding transactions, and rebuilding reports. They will decide what the company is trying to accomplish, how much risk it will accept, where capital should go, and which decisions still require human judgment. They will design policy and examine exceptions. Agents will carry out the ordinary work within those boundaries and produce evidence for the decisions that remain.

The close should become continuous. The forecast should change when the underlying evidence changes. A budget should operate as a living set of constraints, not a spreadsheet the company compares with reality weeks later. Finance should be present when a commitment is being considered, well before the transaction reaches the ledger.

This does not make finance less important. It places financial judgment inside every consequential action the company takes.

The companies that learn to operate this way will behave differently. A five-person company will be able to maintain the financial discipline of a much larger organization. A global business will not need to build a large back office for every country it enters. A controller will supervise a fleet of specialized agents instead of a queue of repetitive tasks. A founder will see the effect of a decision before discovering it in the bank balance.

Solomon is being built for that company.

Money is becoming programmable, but authority is not

The infrastructure for moving money is changing quickly.

Agents can already receive payment credentials, create cards, pay invoices, use financial accounts, and purchase services through machine-readable protocols. Stablecoins make it possible to hold and settle value globally without asking every business to assemble a separate banking stack in every market. Over time, the rail should become an implementation detail. The company states what it wants to accomplish, and the system chooses how value should move.

Faster and more programmable money solves an important problem. It also exposes a harder one.

An agent being technically able to pay does not mean the company intended to buy. Access to a payment token does not establish the agent’s authority to accept a contract. A transaction settling successfully does not prove that the amount was correct, that the work was accepted, or that the payment helped the company.

The next financial infrastructure layer therefore cannot be only about movement. It must carry intent, identity, authority, evidence, and consequence.

Before an agent commits the company, someone should be able to answer:

• Which company and which principal does this agent represent?
• What action is it trying to take?
• What evidence does it have?
• What limit, budget, or policy applies?
• Which person must approve an exception?
• What other commitments does this action affect?
• What will be recorded if the action proceeds?

Those answers cannot live inside the agent’s prompt. They need to survive model changes, employee departures, system migrations, and disputes with counterparties. They must be enforceable outside the model that proposes the action.

This is one of Solomon’s central jobs: make the company’s economic authority explicit enough for software to use and strict enough for people to trust.

Financial software remembers amounts and forgets reasons

The problem exists before agents enter the picture.

Suppose finance is deciding whether the company can afford another employee. Sales knows a major renewal is slipping. Operations has approved an annual software contract. A customer has promised to pay a large invoice on Friday. None of that has reached the forecast. A week later, the bank balance is the first place where every decision meets.

The ledger will eventually contain the transactions. It will not contain the reasoning that would have helped the company while the decision was still open.

Why did the customer pay late? Was the invoice forgotten, disputed, or trapped in procurement? Why was the software bill approved? Was it part of the budget, or was approval conditional on the renewal? What assumptions supported the hire? Who raised a warning, and why was it dismissed?

Those answers usually live in email, Slack, meetings, spreadsheets, and people’s heads. The collections system sees an overdue invoice. The bill-pay system sees an approval. The forecasting tool sees a number entered last week. Each system keeps its own object and discards the relationship between them.

Solomon needs to preserve the reason alongside the amount. It should help while the decision is still open, distinguish advice from permission, and return later to see whether the decision worked.

That memory is valuable for a human finance team. It becomes necessary when agents begin acting for the company.

Starting where money enters, leaves, and gets allocated

Solomon begins with three products: Conduitt, Cadense, and Eigenn.

They are separate because the people buying them have different problems. They are connected because cash entering the company, cash leaving it, and decisions about what the company can afford are parts of the same economic state.

Conduitt

Conduitt begins with money customers owe.

A $40,000 invoice marked “60 days overdue” does not tell a collections team what to do. The customer may have forgotten it. Procurement may have changed systems. The work may be disputed. The CFO may have promised payment on Friday and kept every previous promise.

Those situations deserve different follow-ups, escalation paths, and expected payment dates. Conduitt is being built to understand the difference, carry the collection forward across email, text, and calls, and preserve every promise or dispute around the invoice.

The immediate measure is cash collected. The longer-term value is counterparty memory. Conduitt learns how a customer behaves when it owes money, which promises are dependable, where payment gets stuck, and which intervention resolves the problem without damaging the relationship.

Cadense

Cadense begins before money leaves.

A $72,000 software bill can be legitimate and still be wrong for the company. The team may have stopped using the product. The renewal may have surprised the budget owner. A duplicate may already be in the payment run. Approval may have depended on revenue that did not arrive.

“Awaiting approval” is not enough information to make the decision. Cadense is being built to recover the context, verify the vendor and payment details, detect duplication or fraud, test the bill against contracts and policy, and bring the unusual case to the correct person.

Over time, Cadense should begin earlier than the invoice. It should understand the request, negotiation, contract, purchase order, approval conditions, delivery, invoice, and settlement as one commitment. The company should not discover a bad obligation at the final step when the easiest response is to pay it.

Eigenn

Eigenn begins when someone has to decide what the company can afford.

Suppose the founder wants to hire a sales leader. The answer depends on which invoices will arrive, which bills are committed, whether the renewal closes, when the employee starts, and what happens if several assumptions fail together.

Eigenn is being built to make those dependencies visible before the offer is signed. It should show the evidence behind the answer, let the company test different scenarios, and identify the events that would change the recommendation.

In the future, Eigenn becomes the capital allocation layer for the entire company. Every proposed hire, contract, discount, refund, campaign, and investment can be evaluated against the same current view of cash, risk, and expected return. People set priorities and risk tolerance. Agents continuously update the state, test options, and carry approved decisions into the systems where work happens.

Each product must be worth buying on its own. A collections leader does not need to adopt an economic operating system to collect an invoice. A controller should be able to buy Cadense and stop there. A founder can use Eigenn without replacing the rest of the finance stack.

The larger system earns the right to exist by solving these immediate problems first.

The Financial Consequence Graph

Traditional systems organize information around objects: invoices, bills, accounts, contracts, and transactions. Solomon needs those objects, but it also needs the sequence connecting them.

Imagine an $80,000 invoice due on August 15. The customer says procurement caused a delay and promises to pay on August 29. Conduitt records the promise. The cash plan moves the expected date. A hiring decision stays open because the money has not arrived. August 29 passes without payment. The forecast changes again, the collection escalates, and the company delays the hire.

The invoice is one record. The financial consequence is the full chain: the obligation, the promise, the expectation, the decision that depended on it, the missed date, the response, and the result.

The Financial Consequence Graph is the memory Solomon can build from these chains. It connects:

• people, agents, companies, and accounts;
• invoices, bills, contracts, orders, approvals, and payments;
• promises, conditions, assumptions, policies, and limits;
• decisions, actions, exceptions, and outcomes.

The graph should answer more than “what happened?” It should explain who knew what, which evidence was available, what authority existed, what the company expected, and how reality differed.

This same memory applies to a bill approved only if a renewal closes, a refund stopped by an agent’s limit, or a customer payment plan that changes the cash forecast. It also contains the company’s current beliefs about expected cash, committed spending, hiring, revenue, risk, and the assumptions supporting the plan.

When evidence changes, the company’s view of the future should change with it. A person should be able to inspect why. An agent acting later should inherit the updated state instead of repeating the original mistake.

Accounting systems became indispensable by owning the record of completed transactions. Solomon can become indispensable by owning the record of economic decisions and their consequences.

The company needs a financial constitution

A company run partly by agents needs more than permissions scattered across applications.

It needs a financial constitution: a machine-readable account of who may act, what they may do, under which conditions, with what evidence, and where human judgment is required.

The constitution should govern people and agents consistently. A collections agent may contact a customer but require approval before offering a discount. A procurement agent may negotiate within a price range but lack authority to sign a multi-year commitment. A support agent may issue routine refunds but stop when the refund changes a material customer or cash position. A treasury agent may move idle cash only among approved institutions and only while liquidity remains above a defined threshold.

These rules must be specific, visible, versioned, and easy to revoke. They cannot depend on the model remembering an instruction. The system should enforce them at the moment of action and keep the evidence afterward.

Solomon must also evaluate whether a permitted action is financially sensible. Policy answers whether an agent may act. The Financial Consequence Graph helps answer whether it should.

That distinction matters. A collections agent may be allowed to extend payment terms, but the cash plan may make the extension harmful. A purchasing agent may remain inside its budget while duplicating a tool the company already owns. An authorized action can still produce a bad outcome.

Solomon should bring company-wide financial judgment to the point where the action occurs.

From workflows to a company runtime

Most finance automation still begins with a queue. Software moves work through the same sequence people once followed, only faster.

That is useful, but it is not the end state.

In a company built around agents, economic work can run continuously and in parallel. When a new contract appears, agents can examine legal terms, vendor risk, budget, cash impact, accounting treatment, and required approval at the same time. When a customer promise changes, the collection plan, expected cash, and dependent decisions can update immediately. Reconciliation can begin when the obligation is created rather than after the bank file arrives.

Solomon should become the runtime coordinating that work.

Every consequential action follows a common lifecycle:

1. Intent: A person or agent proposes an economic action.
2. Evaluation: Solomon determines the expected financial effect and gathers evidence.
3. Authority: The financial constitution establishes whether the actor may proceed or who must approve.
4. Commitment: The company makes a promise to an employee, customer, vendor, investor, or another agent.
5. Execution: The appropriate system carries out the action and chooses the payment or communication rail.
6. Settlement: Money, goods, or services are exchanged and reconciled.
7. Outcome: Solomon compares what happened with what the company expected and updates future decisions.

Today, these stages are split across departments and applications. No system owns the full loop. Solomon’s long-term position is to coordinate it without replacing every application involved.

This is larger than an autonomous finance department. It is a way for the company itself to become financially coherent as more of its work is performed by software.

Autonomy must be earned from evidence

I do not believe a company should activate an autonomous finance department and trust the demo.

Solomon should first observe the work and explain what it sees. Then it can prepare an email, approval, payment, or forecast for a person. Once it proves dependable in a narrow routine, the company may allow it to perform that routine inside a defined boundary.

The evidence should be ordinary and measurable. Did the reminder collect the invoice without hurting the relationship? Did Cadense catch duplicates without blocking legitimate purchases? Did the cash forecast remain close to the outcome? When policy required a person, did the agent stop? When an assumption failed, did the system notice quickly enough to matter?

Different agents will earn different levels of autonomy. A low-risk reminder may become automatic after dozens of successful cases. A material contract, unusual payment, or new counterparty may always require a person.

Authority should expand because the record supports it, not because the model claims confidence.

Over time, the Financial Consequence Graph becomes the evidence base for autonomy. It shows where an agent is dependable, where it fails, which conditions create risk, and how much authority the company can safely delegate.

When companies and agents transact with each other

The internal finance team is only half of the problem.

One company’s receivable is another company’s payable. The seller’s records say a customer owes $80,000. The buyer’s records say it owes a vendor $80,000. Both are describing one economic obligation.

Today, the companies create separate records, exchange documents, investigate the same dispute twice, and make different guesses about settlement. Their agents will inherit this fragmentation unless a shared coordination layer exists.

If both companies choose to connect through Solomon, they should be able to agree on the parts of the obligation they already share:

• the parties and authorized agents;
• the goods or services promised;
• the amount, currency, and payment terms;
• whether delivery or acceptance occurred;
• any dispute, condition, or promised date;
• the approvals required on each side;
• the final settlement and its evidence.

Neither company should expose its private forecast, bank balance, margins, or internal deliberations. Each side controls what it reveals and for how long. The shared obligation contains only the facts needed to coordinate the transaction.

This could remove enormous amounts of duplicated work. An accepted delivery can update both sides. A disputed amount can stop an inappropriate collection and an incorrect payment at the same time. A payment promise acknowledged by the buyer can update the seller’s forecast. Reconciliation begins from a common obligation instead of two stale copies.

As agents begin negotiating with other agents, this shared layer becomes more important. Each side needs to verify whom the agent represents, what it may commit to, and whether the resulting agreement is enforceable inside the company’s rules. The agent’s fluency is irrelevant if its authority cannot be established.

Solomon can become the trust and coordination layer for this agent-to-agent economy.

Settlement should become an implementation detail

Companies currently organize financial operations around the limitations of payment rails: cutoff times, bank portals, currencies, correspondent banks, card networks, wallet addresses, and settlement delays.

Those limitations will not disappear at once, but the company should eventually stop managing them manually.

Once an obligation is approved, Solomon should be able to select the appropriate way to settle it based on cost, speed, currency, liquidity, risk, privacy, and counterparty preference. The payment may use ACH, a wire, a card, an instant-payment network, or a stablecoin. The company should care about the outcome and the controls, not the mechanics underneath.

Solomon does not need to own every rail. Banks, payment processors, stablecoin networks, and treasury providers are building that infrastructure. Solomon’s position is to know why value should move, whether the movement is authorized, how it affects the company, and whether the obligation was actually satisfied.

This distinction lets Solomon work across rails instead of betting the company on one of them.

A portable operating financial reputation

After years of work, the Financial Consequence Graph may contain a better account of a private company’s behavior than a periodic financial statement can provide.

It may show that accepted invoices are normally paid within four days, that management responds quickly when cash deteriorates, that forecasts have become more accurate, or that the company keeps commitments even when payments are late. It may also reveal which promises deserve less confidence and where operations repeatedly fall short.

This should not become a score imposed on the company by Solomon. It should be a portable operating financial reputation built from the company’s own decisions and outcomes, owned by the company and shared only with permission.

That record can eventually change how private companies obtain working capital, insurance, treasury services, payment terms, and trade credit.

A lender may rely less on a stale year-end statement if the company can prove how quickly receivables convert to cash and how management responds to shortfalls. A supplier may extend better terms if the buyer can demonstrate a history of honoring commitments. An insurer may price risk more accurately if the company can show how controls behave in practice. An investor conducting diligence may inspect evidence of operating discipline without receiving unrestricted access to every internal record.

This is where Solomon’s long-term economic impact can extend beyond software efficiency. Small and private companies often receive worse financial terms because outsiders cannot see how they actually operate. A permissioned history of decisions and outcomes can reduce that information gap.

Solomon is not a lender, bank, insurer, underwriter, or credit bureau today. It has not earned the right to become one. First, the products must create value. The graph must improve decisions. The constitution must control action. The record must remain trustworthy for years.

Only then should Solomon help capital move toward companies that use it well.

What compounds

A competitor can connect to an accounting system and import seven years of transactions. Customers should be able to move their data, so Solomon cannot depend on trapping it.

What is harder to reproduce is the history around the transactions: which promises proved reliable, which approvals were conditional, what each agent was allowed to do, which recommendations management rejected, and which actions changed the outcome.

Solomon sees the decision while it is open, applies the authority around it, follows the commitment across systems, and returns for the result. That creates a feedback loop that a static import cannot reproduce immediately.

The network can compound too. Each additional connected counterparty makes shared obligations easier to coordinate. Each supported agent can operate against the company’s existing authority instead of creating another isolated policy system. Each payment rail gives the runtime another settlement option without changing the obligation above it.

The strongest position is not ownership of the customer’s raw data. It is becoming the trusted system through which the company understands, authorizes, coordinates, and learns from economic action.

The customer must remain able to leave. Solomon earns permanence by becoming useful, not by making departure impossible.

What Solomon will not rebuild

Accounting systems should keep the books. Banks and payment networks should hold and move money. CRMs, payroll products, inboxes, procurement systems, and agent platforms should continue doing the work they already own.

Solomon should connect to those systems and provide the economic state and authority they lack. It should govern consequential actions without demanding that every action occur inside a Solomon interface.

The company may choose its own sales agent, support agent, procurement agent, or treasury provider. Solomon should make it possible for each one to work from the same financial truth and the same enforceable rules.

The products will remain independently useful. Conduitt should collect receivables without Cadense. Cadense should control payables without Eigenn. Eigenn should support decisions without replacing the accounting system. Shared infrastructure should improve each product without turning the suite into a forced bundle.

Solomon will also avoid pretending that autonomy eliminates responsibility. People remain responsible for the company’s goals, risk tolerance, policy, and exceptional decisions. Software can carry more work, but it cannot make accountability disappear.

What success looks like in 2046

By 2046, a company should be able to begin operating globally without assembling a separate finance department and banking workflow in every country.

Its books should remain current. Its forecast should update when evidence changes. Every agent should have a verifiable identity, a defined scope of authority, and a record of its actions. Routine obligations should be negotiated, approved, reconciled, and settled with little manual work. Material exceptions should reach the right person with the relevant evidence already assembled.

A five-person company should be able to supervise thousands of daily financial decisions without losing control. A global company should be able to operate faster as it grows instead of burying every decision under another layer of process.

When two companies transact, their agents should be able to coordinate the shared obligation, prove their authority, and settle through the appropriate rail while each company keeps its private information private.

When a company seeks capital, insurance, or trade terms, it should be able to carry a permissioned history of how it makes and keeps financial commitments. Good operating behavior should become legible and financially valuable.

The economic infrastructure for the internet made it easier for anyone to accept a payment. The next infrastructure layer must make it possible for companies and agents to make commitments, exercise authority, coordinate obligations, and allocate capital without losing the reasons and controls that make commerce trustworthy.

That is the layer I want Solomon to build.