Explore what connected systems and AI can make possible, and the context, process owners and judgment needed to use them well.
Written notes to explore now. Proposed video topics for our November content focus.
01 / Shared context
Start with a shared meaning.
A unified view should help people answer the same business question using shared definitions. That starts with the data model: how customers, contracts, locations, orders and invoices relate—not just whether an agent can retrieve them.
Illustrative example
One contract. Several views of the customer.
Sales may record one customer, finance may bill several entities, and delivery may work by location. “Revenue by customer” can mean different things to each team. Map the relationships with the process owners and agree what sold, billed and delivered mean. Then explore what a shared view or agent could help the team understand.
A question to bring to the workWhich records—and which definition—should this answer use?
Maintained data and useful context support better outputs. They do not remove the need to check the reasoning, tools and result.
When updates are inconsistent, an agent can repeat a stale view of the business. Adoption and data-model maintenance need to be part of the operating routine, not just a training session at launch.
Illustrative example
A signed deal changes after handover.
Who records the change? Who checks the billing impact? Who updates the information the agent will see? Work through the handoff with the people in sales, operations and finance, then coach them on the actual exceptions they face.
A question to bring to the workWho owns the update, the check and the next step?
A connection between systems does not create adoption on its own. Process owners need a workable routine, usable guidance and a way to flag what is not working.
Tools, MCP connections, memory and permissions give agents more ways to work across systems. They also make it important to define authorized actions, approval points and what context may be retained or reused.
Illustrative example
An agent drafts a contract change.
The workflow may allow it to read approved records and prepare a recommendation. If a person must approve the change, that approval needs to be enforced before a write. The record of the run should make the inputs, tools and actions inspectable.
A question to bring to the workWhat can it read, remember or change—and who approves?
Access, retention and recovery rules depend on the workflow. Connecting a tool is one part of the design, not a substitute for those decisions.
Agree what improvement means with the process owner before automating. Establish a baseline for the current process. Use ordinary cases and awkward exceptions to check outputs and actions, rather than judging the workflow only on its best demonstration.
Illustrative example
Test a quote update with missing information.
Try a missing location, an outdated price or an ambiguous request. Check whether the workflow asks for help instead of silently committing a bad change. Possible measures include corrections needed, exceptions routed appropriately and review effort—not only speed.
A question to bring to the workWhat evidence would make the process owner comfortable using this?
A small set of evaluations cannot establish reliability in every situation. Review failures and update the checks when the workflow or its data changes.
In Hubsessed Office Hours, Ryan and Chris follow one customer through booked, billed, earned and collected revenue. The full replay may require sign-in.
