Team of Teams and AI Agents

An internal initiative exploring how employees, departments, and AI agents can work together through shared tools, clear governance, and productized workflows.

Context

The idea began after Lean's CEO took part in a Team of Teams initiative at the Ministry of Health.

The model brought people from different organizations together around one shared task, similar to a focused task force. The experience showed how a cross-functional group could move faster when it shared one outcome, reduced handoffs, and worked outside normal departmental boundaries.

Lean adopted the concept internally and created two broad Team of Teams directions.

One direction focused on improving existing products, preparing them for the market, and supporting launch and commercialization.

The second direction focused on AI.

The AI initiative began with three connected workstreams:

1. Understand how departments work and find where AI could improve daily tasks.
2. Reduce dependencies between teams by giving employees AI tools, shared methods, and clear governance.
3. Build one platform where employees and AI agents could work together.

The workstreams overlapped, so they were later combined into one initiative.

The central idea is larger than an internal chatbot. It is an operating model where:

• Employees can assign work to agents.
• Agents can use approved tools.
• Agents can collect information.
• Agents can contact people or systems when allowed.
• Agents can update task status.
• Agents can create outputs.
• Agents can request approval.
• Humans remain responsible for sensitive decisions.
• Teams can reuse capabilities instead of building isolated automations.
• The company can learn which internal solutions could become products.

The initiative aligned closely with the direction I wanted to grow into after moving from UX/UI to software engineering. It combined product thinking, development, AI, architecture, stakeholder management, adoption, and organizational change.

Problem

The initiative addresses several connected problems inside a large company.

1. AI use was fragmented

Different employees and teams were already experimenting with AI, but the work could remain isolated.

Common risks included:

• Repeated experiments.
• Different tools solving the same problem.
• No shared standards.
• Limited reuse.
• Weak visibility into what already existed.
• Inconsistent quality.
• Unclear ownership.
• Security and governance concerns.

The company needed a shared direction rather than a collection of personal tools.

2. Repetitive work consumed skilled employees

Many tasks required people to:

• Search for information.
• Follow up with several departments.
• Rewrite common documents.
• Collect status updates.
• Move data between systems.
• Prepare reports.
• Create routine outputs.
• Wait for another team to complete a small dependency.

These tasks were necessary, but they reduced the time available for decisions, quality, creativity, and higher-value work.

3. Teams depended on one another for small actions

A request could move across several teams before it was completed.

This created:

• Waiting time.
• Repeated follow-up.
• Lost context.
• Unclear accountability.
• Work that stopped when one person was unavailable.
• High coordination cost for simple tasks.

The initiative needed to reduce unnecessary dependencies without removing governance or control.

4. Agents needed access to tools, not only language

A useful enterprise agent needs more than a prompt box.

It may need approved access to:

• Internal knowledge.
• Internet search.
• Task systems.
• Email.
• Collaboration platforms.
• Documents.
• Data.
• Product environments.
• Testing tools.
• Reporting systems.

This creates design and engineering questions around permissions, identity, audit logs, error handling, escalation, and human approval.

5. Humans needed to remain in control

AI can accelerate work, but enterprise use needs boundaries.

The initiative needed to answer:

• What can an agent do alone?
• What always needs approval?
• Who owns the result?
• How does a user understand what the agent did?
• How can a user correct the agent?
• What happens when the agent is uncertain?
• How are actions logged?
• How is sensitive data protected?
• How can teams trust the output?

6. Internal ideas needed a path to productization

Some solutions could remain internal tools. Others might become products or services that Lean could offer.

The initiative therefore needed to think about:

• Reusable capabilities.
• Product boundaries.
• User groups.
• Business value.
• Technical architecture.
• Governance.
• Support.
• Pricing or commercialization.
• Adoption.
• Measurement.

7. Adoption required more than building the technology

Employees needed to understand how AI affected their work.

Without clear communication, people could see the initiative as:

• A replacement threat.
• Another tool they had to learn.
• A leadership experiment.
• An unclear platform with no connection to their daily tasks.

The initiative needed an adoption story that focused on support, capability, and better work.

My Role

My role sits at the intersection of software engineering, product thinking, user experience, AI adoption, and internal communication.

This project is still in progress, so my responsibilities continue to develop.

Product contributor

I contribute from a product perspective by helping turn broad AI ambitions into clearer user needs, workflows, capabilities, and outcomes.

My focus includes:

• Understanding the employee problem before choosing an AI solution.
• Defining what an agent should help with.
• Mapping how a task moves between a person, an agent, and another system.
• Identifying where human review is needed.
• Thinking about the experience across assignment, progress, approval, output, and follow-up.
• Separating reusable platform capabilities from one-off automations.
• Considering how internal ideas can become supported products.

Software engineering contributor

After moving into the Corporate IT team, I began building a stronger foundation in production engineering.

My intended and developing contribution includes:

• Understanding the architecture behind the agent platform.
• Learning how tools and integrations are exposed to agents.
• Supporting front-end experiences for employees and operators.
• Building and improving internal applets and workflows.
• Exploring agentic automations.
• Supporting development, testing, deployment, and iteration.
• Connecting product decisions to technical constraints.
• Learning how enterprise systems move through staging, UAT, and production.

AI champion

Before this initiative, I had already introduced AI tools and workflows inside the Digital Experience team.

I:

• Initiated and hosted AI-in-UX workshops.
• Tested AI tools for research, writing, ideation, wireframing, prototyping, and reports.
• Helped team members use the tools in real work.
• Supported prompt design and better input structure.
• Helped leadership evaluate and subscribe to useful tools.
• Built applets, workflows, and agentic automations to reduce manual effort.
• Encouraged the team to treat AI as part of the process rather than a one-time experiment.

That experience gave me a practical view of adoption. People use AI when it solves a real task, fits the workflow, and produces results they can trust.

Internal facilitator and presenter

I was selected to help introduce the initiative internally.

My responsibilities for the introduction session included:

• Opening the event.
• Introducing the purpose.
• Moderating a leadership discussion about Lean's AI direction.
• Managing audience questions.
• Moving between the session sections.
• Connecting leadership discussion to the practical agent demonstrations.
• Closing the event with a clear message.

This role required me to understand the initiative from both the leadership and employee perspectives.

Cross-functional bridge

My previous UX/UI experience helps me communicate across different groups.

I can discuss:

• User needs with employees.
• Product value with business leaders.
• Flows and interfaces with designers.
• Feasibility with engineers.
• Data and AI needs with technical teams.
• Adoption with operations and governance stakeholders.

This is valuable in an initiative that does not belong to one discipline.

Approach

1. Start with work, not AI

The initiative should not begin by asking where to place an agent.

It should begin by asking:

• What work takes too long?
• Where do employees wait?
• Which tasks are repeated?
• Which steps require judgment?
• Which steps require only collection or formatting?
• Where is context lost?
• What creates avoidable dependency?
• What outcome matters?

This keeps the work tied to a real business need.

2. Map the current workflow

Before designing the future state, the current process needs to be visible.

A workflow map can show:

• Trigger.
• Requester.
• People involved.
• Systems used.
• Manual steps.
• Waiting points.
• Repeated decisions.
• Required approvals.
• Sensitive information.
• Final output.
• Success measure.

This exposes where AI can help and where it should not be used.

3. Define the human and agent roles

For each use case, the system should state clearly:

• What the employee owns.
• What the agent can prepare.
• What the agent can execute.
• What requires approval.
• What the agent cannot access.
• How the employee can edit the result.
• How the agent explains its work.
• How failure is handled.

The goal is not full automation by default. The goal is the right level of support for the risk and task.

4. Design a reusable agent model

Instead of building every use case as a separate product, the initiative can use shared capabilities.

Possible shared capabilities include:

• Task intake.
• Planning.
• Search.
• Internal knowledge retrieval.
• Document creation.
• Communication.
• Status updates.
• Approval requests.
• Audit logs.
• Notifications.
• Human escalation.
• Tool permissions.
• Output review.

This can reduce duplication and create a platform that grows with new use cases.

5. Keep the human in the loop

Human approval should match the level of risk.

A simple model could include:

Low risk

The agent can complete the task and show the result.

Examples:

• Summarize public information.
• Reformat text.
• Draft a routine document.
• Organize notes.

Medium risk

The agent prepares the work, but the employee approves before action.

Examples:

• Send an internal message.
• Update a task.
• Create a report using internal data.
• Suggest a response.

High risk

The agent can assist but cannot complete the final action.

Examples:

• External communication.
• Sensitive data access.
• Financial decisions.
• HR actions.
• Production changes.
• Legal or regulatory output.

6. Design transparent agent interactions

The user should understand:

• What the agent is doing.
• Which information it used.
• What stage the task is in.
• What action is waiting for approval.
• What changed after user feedback.
• Whether the output is complete.
• What failed.
• Who owns the next step.

A good agent experience should reduce uncertainty, not create a hidden process.

7. Build small, testable use cases

A large platform vision needs small proofs.

Useful early use cases should be:

• Frequent.
• Time-consuming.
• Clear.
• Low or medium risk.
• Easy to measure.
• Valuable to a real team.
• Reusable elsewhere.

Each use case should test both the technology and the operating model.

8. Treat governance as part of the product

Governance should be designed into the experience.

This includes:

• User identity.
• Role-based access.
• Tool permissions.
• Data boundaries.
• Logs.
• Approval rules.
• Retention.
• Model and prompt versioning.
• Quality review.
• Incident handling.
• Ownership.

A governance document alone is not enough if the platform interface does not enforce it.

9. Support adoption through education

The internal launch and follow-up communication should help employees understand:

• Why the initiative exists.
• Which work it will support.
• How people remain responsible.
• How to suggest use cases.
• How to access tools.
• Where to get help.
• How success will be measured.
• What the initiative is not.

10. Think about productization early

For any capability that may become an external product, the team should ask:

• Is the problem common outside Lean?
• Can the workflow be standardized?
• What needs configuration?
• What data and integrations are required?
• Who buys it?
• Who uses it?
• How is it supported?
• What is the value compared with existing tools?
• What governance would a client need?
• Can it operate across different organizations?

This connects internal innovation to company growth.

What I Built

The initiative is active, so this section separates completed work from developing contributions.

Completed foundation from earlier AI work

Before joining the initiative, I had already created practical AI adoption inside my previous team.

I built or supported:

• AI-assisted research workflows.
• Tools for survey planning and scenario generation.
• Prompt structures that improved output quality.
• AI-assisted UX writing.
• Ideation and wireframing workflows.
• Rapid prototypes.
• Interactive reports that replaced manual report production.
• Small applets for internal tasks.
• Agentic automations that combined several steps.
• Workshops and team support.
• Tool evaluation and adoption.

These experiments showed where AI created real value and where human review remained necessary.

Internal introduction experience

I prepared to support the internal introduction of Team of Teams.

My work included:

• Understanding the initiative's history and purpose.
• Translating the strategy into a clear employee story.
• Preparing session transitions.
• Structuring leadership questions.
• Planning how to manage audience questions.
• Connecting the strategic discussion with practical demonstrations.
• Helping the session feel like one narrative rather than separate presentations.

Product and experience thinking

I have been exploring how the platform experience can support:

• Assigning a task to an agent.
• Showing the agent's plan.
• Tracking status.
• Requesting information from the employee.
• Calling approved tools.
• Showing human approval steps.
• Presenting results.
• Revising an output.
• Escalating uncertainty.
• Closing the task.
• Recording the history.

Technical and product ownership direction

My goal within the initiative is to contribute to the full lifecycle:

• Use-case discovery.
• Business requirement.
• User flow.
• Interface.
• Front-end implementation.
• Agent integration.
• Back-end understanding.
• Architecture.
• Quality assurance.
• UAT.
• Release.
• Measurement.
• Iteration.
• Productization.

This is the type of work that motivated my transfer from UX/UI into software engineering.

Safe portfolio simulation

For the public portfolio, the initiative can be shown through a fictional, redacted agent workflow.

Example:

1. An employee assigns a task.
2. The agent creates a plan.
3. The agent searches approved sources.
4. The agent asks the employee for missing context.
5. The employee approves an external action.
6. The agent prepares the output.
7. The employee reviews and edits.
8. The task closes with a record of actions.

This explains the product idea without exposing internal systems or data.

Outcome

The initiative is still developing, so the outcome is a combination of current progress and expected organizational value.

Current progress

• Three overlapping AI workstreams were brought under one shared initiative.
• Leadership aligned around a broader view of AI inside Lean.
• The initiative moved beyond isolated tools toward a shared employee and agent platform.
• Internal communication and launch preparation created a clearer story for employees.
• Existing AI experiments and use cases created practical input for the platform.
• The initiative established a space for product, engineering, data, governance, and business teams to work together.

Expected organizational value

The platform aims to help Lean:

• Reduce repetitive work.
• Shorten waiting time between teams.
• Reduce avoidable dependencies.
• Improve access to knowledge.
• Give employees more time for decisions and quality.
• Create reusable AI capabilities.
• Apply governance consistently.
• Improve visibility into automated work.
• Turn useful internal ideas into products.
• Build AI into daily operations rather than treat it as a separate tool.

Personal outcome

The initiative gives me a path to combine the areas where I create the most value:

• Product thinking.
• UX.
• Front-end engineering.
• Software development.
• AI.
• Automation.
• Stakeholder management.
• Facilitation.
• Innovation.
• Ownership.

It also gives me the opportunity to move from designing one part of a product to understanding and contributing to the full system.

What I Learned

AI transformation is an operating-model problem

The model is only one part of the solution. Roles, permissions, workflows, governance, ownership, adoption, and measurement determine whether AI creates value.

An agent needs tools and boundaries

A useful agent needs access to systems, but every tool increases risk. Permissions and approval rules are part of the product design.

Full automation is not always the goal

The best result may be faster human work rather than removing the human. Good design decides which parts should be automated and which parts need judgment.

Trust requires visibility

Employees need to see what the agent did, what information it used, and what action it plans to take. Hidden automation weakens trust.

Adoption starts with useful work

People adopt AI when it solves a task they already care about. A broad strategy becomes real only through clear daily use cases.

Productization changes the questions

An internal automation can rely on local knowledge and manual support. A product needs repeatability, configuration, security, support, ownership, and a clear buyer.

Governance should appear in the interface

Approval gates, logs, permissions, and risk states should be visible parts of the user experience.

Cross-functional leadership matters

AI initiatives touch almost every department. Progress depends on people who can translate between leadership, business, engineering, data, governance, and users.

My UX background remains useful in engineering

Moving into software engineering did not replace my design experience. It gave me a broader way to use it. I can help make technical systems understandable, usable, and connected to real work.

I want to own outcomes, not only tasks

This initiative reflects the direction I want for my career. I want to help take an idea through product definition, architecture, implementation, release, adoption, measurement, and improvement.