One employee knew exactly what a useful contract tracker needed to do. It had to read scanned agreements, pull out the dates and parties, separate final versions from earlier drafts, and surface renewal or termination deadlines 30, 60, or 90 days ahead.
When she worked directly with Omni during a training engagement, the missing piece was not knowledge of the process. It was a technical starting point. She asked for a high-level architecture, a core data structure, initial preprocessing, and one or two working examples she could learn from and modify.
She was not alone. Other employees at the same energy technology company brought their own ideas to the sessions: reminders for employee health examinations, approval records with version history, and an easier way to handle an everyday lunch-ordering process.
Together, those requests raised a practical question: what could employees build if they could bring the workflow knowledge while an AI agent and a technical team helped supply the structure?
Employees brought the process knowledge. Omni helped turn it into a structure they could inspect and refine. Illustration based on documented training interactions.
What employees wanted to build
The ideas were ordinary in the best sense. They came from work employees already understood.
The contract request was the most detailed. The employee wanted scanned agreements converted into searchable records. Useful fields included company identifiers, start and end dates, and the number of previous engagements with a vendor. She also wanted contracts waiting for review to be visible, along with agreements nearing a renewal or termination window.
Other requests came from different parts of working life. Employees described reminders for health examinations and expired records. They discussed approval history and version control. They also raised a lunch-ordering process that caused enough daily frustration to be worth improving.
None of the employees needed a generic list of AI possibilities. They arrived with specific inputs, rules, and outcomes from their own work.
Their experience using Omni
The training put employees in direct contact with Omni. They tried to translate processes they knew into tools and saw where they needed help.
The contract participant described the clearest obstacle. Starting from a blank prompt, experimenting, and debugging repeatedly would take too much time without giving her a satisfactory result. She knew which fields mattered and what the workflow should do, but she was unfamiliar with the development language needed to build it reliably.
Her request was concrete: give her the architecture, data structure, preprocessing, and a few working examples. From there, she wanted to learn, change the examples, and continue shaping the tool.
That is a more useful picture of employee-built software than the claim that anyone can build anything instantly. Employees can bring deep process knowledge. They still need a sound starting structure, examples they can inspect, and technical support for the parts where mistakes carry real consequences.
One practical example: from scanned contract to reviewed reminder
The contract workflow can be broken into five visible steps.
- An employee uploads a scanned agreement.
- Omni prepares a draft record with the counterparty, effective date, end date, status, and responsible owner.
- The employee checks every extracted field and corrects anything that is wrong or incomplete.
- The employee defines which 30-, 60-, and 90-day rules apply to renewal, termination, or review.
- The workflow prepares reminders for the responsible people, with a person still responsible for the final decision.
This example is proposed from the documented request. It is not a deployed client application.
The responsibility split is concrete. Employees define the fields, deadlines, exceptions, and acceptable result. Omni handles the first extraction, prepares the structured record, and applies the configured reminder rules. Technical support establishes the architecture and preprocessing, tests messy scans and missing fields, sets access permissions, and supplies working examples that employees can safely modify.
The employee defines the rules and checks the record; the agent prepares the structure and reminder draft. Proposed workflow using synthetic data.
How different teams could use Omni
The Legal and HR requests also show why one large shared workspace would be the wrong starting point. Contract records and employee health information should not become visible across teams by default.
A proposed pilot design could begin with separate Legal and HR spaces, each with its own data and workflow. The people responsible for the pilot would define who should access each space, then verify those rules before using sensitive information.
This is a design principle for a future pilot, not a description of an interface or permission test already demonstrated with this client.
A relevant next step
The most promising internal tool may already be sitting in an employee's notes, spreadsheet, or daily workaround. The useful starting question is not, “What can AI do for us?” It is, “Which process does someone here understand well enough to specify, but need help turning into a working tool?”
Start with one process. Ask the employee to name the inputs, the rules, the exceptions, and the result they would trust. Then build the smallest example they can review and change.
What would your employees choose first? What kind of project would you want to see Omni solve next? Tell us in the comments.
Top comments (0)