What software becomes
6 min read
Imagine planning a few days away with your family. You ask your agent for five nights within a R$15,000 budget. It finds some options, but looking at the schedule, you wonder whether two more nights would make the trip less rushed. You want to compare the cost, move a few activities, and send both plans to your partner.
I expect software to handle that change as part of the conversation. The agent could create a budget comparison, then add a map and a schedule as you need them. You would end up with a small application for the trip without having set out to build one.
People should be able to do this for their own plans as readily as a team does it for a financial analysis. The result should remain available after the conversation ends, with its data and assumptions intact. I want to return to the thing we were working on, not ask the agent to make it again.
Start with the question
For the trip, the first useful answer depends on who is coming, which dates can move, and what the budget includes. A hotel price means little if it covers one person instead of the family. A cheap stay may leave us spending more on transport.
The agent could use the calendar and saved places I chose to share, then ask about what it cannot establish. It would need to connect each price to the dates, people, and option it covers. A plausible-looking itinerary can still put you somewhere after it closes.
Let the computer calculate
For a simplified comparison, suppose travel costs R$6,400 and the stay plus daily spending comes to R$1,200 per night. The model could identify those inputs and propose the calculation. The application should validate them, execute the formula in ordinary code, and use the results in the chart.
The comparison should keep the five-night plan while adding seven nights beside it. Both use the same rates, so the extra cost comes entirely from the two additional nights. These are sample amounts, not quotes or reservations.
Could we stay two more nights and keep the trip under R$15,000?
With the same nightly costs, seven nights would leave R$200 in the budget.
Family trip
Budget comparison- 5 nights
- R$12,400
- 7 nights
- R$14,800
- Fixed travel costs
- R$6,400
- Stay and daily spending
- R$1,200 × nights
Keep both plans. I'll check the dates with my partner.
Sample costs, not live quotes. Only the number of nights changes; the rates and fixed costs stay the same.
Once the calculation works, changing the number of nights should rerun it through ordinary code, without another model call. Asking for a different kind of comparison might require the agent again. For example, it could add the cost of renting a car and compare that with staying nearer the places we want to visit.
The formula still needs checking. Did it count the flight once per person or once for everyone? Did it include the hotel twice? And before relying on either plan, the agent would need fresh availability and prices. Correct arithmetic cannot make an expired quote bookable.
The screen the work requires
The budget comparison could appear inside the chat. When we start choosing where to stay, the same plan could open into a map with travel times. A daily schedule would make it easier to see why five nights felt rushed. Moving an activity should update that plan, not create another answer I have to reconcile with the previous one.
My partner should be able to open the shared itinerary and move an outing directly, without knowing how I prompted the agent. We could keep both versions and return to them while away, with reservations beside the activities they belong to. Sharing the plan should not expose either person's private conversations.
I would hate software that rearranged the whole screen every time I spoke to it. A useful chart should stay where I left it. The product could assemble tested tables, filters, and charts, generating something new when the task needs it. Adaptation should let me keep the parts that work.
A question about gross margin
A CFO asking why August's gross margin fell in Brazil would need the same ability to turn a question into something she can inspect. Her agent would have to connect warehouses, orders, revenue, and costs using the company's definitions. An unusual freight charge could explain a change or reveal a classification error. She would need to open the supporting entries, not trust a plausible explanation.
A long chat transcript would be a terrible place to review this analysis. The software could create a chart of the margin change and a table of the entries behind it, with unresolved items marked. Both views would use the same records and calculation.
Suppose August revenue is R$1,000,000 and costs are R$700,000, giving a 30% gross margin. The CFO asks what September would look like if a warehouse migration ended and R$60,000 of costs disappeared. Holding everything else fixed gives 36%. The software should execute that calculation, with the proposed reduction kept separate from recorded costs.
Beside the August result, the agent could add the September scenario with editable assumptions. The original analysis stays available while the CFO tests a delayed move or a different freight rate. As with the two trip plans, changing an assumption creates a comparison, not a change to what already happened.
What if the migration costs disappear?
August Recorded
- Revenue
- R$1,000,000
- Recorded costs
- R$700,000
Original analysis stays unchanged.
September Scenario
- Remove migration costs
- −R$60,000
- Scenario costs
- R$640,000
R$360,000 gross profit ÷ R$1,000,000 revenue
Only the cost assumption changes. Revenue and everything else stay fixed.
Work continues when the conversation stops
The trip may be waiting for my partner to confirm two extra days off. Closing the conversation should leave that question attached to the seven-night plan. When they confirm, the agent could check the affected dates and update the options, showing which prices changed. Any existing reservation should remain separate from a proposed replacement.
The finance team might be waiting for the controller to confirm whether a charge belongs in the migration scenario. Her answer could change the calculation, while the version already discussed in a meeting remains available. Testing the scenario should leave the ledger untouched.
This requires an agent runtime that keeps the job going across tools and interruptions. The interface is one way into that job. Closing the conversation should not discard its progress, and opening the chart should not start a separate version of the work.
What changes next time
After the trip, I might tell my agent that the schedule was still too packed. On the next one, I would expect it to leave more time between activities and show me that choice. It should check who is coming rather than assume every trip has the same people or pace.
The finance team could also get a different starting point next month. If the CFO repeatedly opens freight by warehouse, the report could offer that breakdown. If the controller corrects how migration costs are classified, an approved rule could change the next calculation.
When I start planning again, I would want to open the previous trip, keep the parts we liked, and ask for a quieter version on new dates. I could spend that conversation deciding what to change instead of finding the itinerary and reservations in old messages.