Selected work

AI governance had arrived as separate feature requests across Cisco. Teams were building first-party agents. Customers were defining second-party agents inside Cisco platforms. Tools such as Codex and Claude Code brought third-party agents into the same environments.

Each product could make its own decisions about identity, permissions, context, risk, evidence, cost, and recovery. I led the work to define the shared platform, the points of enforcement, and a product model teams could challenge and build.

Administrators needed clear answers: Who owns this agent? Whose authority is it using? What can it reach? What changed? How do I stop it? Trust in those answers determined whether customers would allow agents to change services, reach sensitive data, or act across customer boundaries.

The same consequential action could receive different treatment in Dashboard, another product, an API, or MCP. An interface-level control also left a path for APIs and other surfaces to bypass it.

The platform needed one enforceable control point and a model customers already understood. Ownership, delegated authority, scope, limits, approval, evidence, intervention, and recovery became the language of the product.

I wrote the platform PRD around six requirements:

• Visibility and control.
• Access control.
• Storm control.
• Shared context and memory.
• Automated trust delegation.
• A model Cisco customers already understood.

We mapped harm to policy, risk, evidence, enforcement, and recovery. Authorization, blast radius, reversibility, operating state, and human approval entered the product model at the start.

I expanded our Double Diamond with AI to compress the loops between evidence, exploration, and commitment. I used it to synthesize research, generate edge cases, and turn hypotheses into working code, interaction, and motion; Design, Research, Product, and Engineering then challenged the same PRD and running prototype while the model was still flexible. This shortened the path from research signal to testable behavior while customer evidence and team judgment still drove decisions.

I made the governed action contract the required front door for consequential actions across product interfaces, APIs, and MCP. The same action receives the same policy decision wherever it begins.

At that boundary, the platform returns one of four decisions: allow, constrain, require approval, or deny. The product that owns the side effect executes it. The shared layer applies policy, records evidence, supports intervention and exceptions, and maintains the audit trail.

For each consequential action, the system preserves the state before the action, the attempted change, the policy decision, affected objects, resulting state, and recovery outcome.

I set the MVP at three commitments: access control, storm control, and a single management plane. The intended experience shows who delegated authority, what the agent can touch, which limits apply, when approval is required, and how to pause or recover the action.

Hands-on

I wrote the platform PRD, defined the six requirements and MVP, set the enforcement boundary, and used working code and motion to resolve product decisions. I set the visual and interaction direction and stayed close to implementation as the model became real.

Leadership

I coordinated Dashboard, product surfaces, Action Center, APIs, and MCP around one product model. I also helped designers use AI to build code, interaction, and motion fluency so the team could test ideas earlier and carry stronger decisions into implementation.

The early exploration combined design strategy with research and evidence from adjacent role-based access work. The wider team supported Cisco Live testing and showed where the model worked and where it confused people.

A product designer led detailed work on guardrails, runtime safety, budgets, memory, permissions, and supervision. Other design partners shaped the product framework and the separate Action Center experience.

Product and Engineering challenged the API boundary, recovery model, and split between shared policy and domain-owned execution. Ownership, naming, and product placement are still open.

The PRD, enforcement rule, MVP, roadmap, and working interaction now guide implementation across the program.

Teams have one shared model for first-party, customer-defined, and third-party agents. The first release has a clear boundary and a focused scope: access control, storm control, and one management plane.

Customer adoption, production safety, and business impact are still unmeasured.

New interaction models earn trust when their controls feel familiar. People do not need to understand the model, but they do need clear limits, visibility, intervention, and recovery.

Prototyping in code gets us to better interactions and motion faster. Testing also gets better because people can leave the happy path and see how the system actually behaves.

Large companies could buy cloud infrastructure faster than they could connect and operate it. Even mature teams relied on manual tunnels, scattered scripts, and a different interface for every provider.

Cisco was entering a cloud-native domain beyond its campus and data center products. We needed to define the experience while the underlying system, market position, and team model were still taking shape.

The work began as MCN, Multicloud Networking, and reached Public Preview as Multicloud Fabric. Both names describe the same product lineage.

Customers were assembling one network from cloud-provider consoles, CLI work, scripts, tunnel managers, and on-premises systems. Connecting cloud workloads back to campuses and data centers added another layer of fragility. One zone failure could spread because resilient routing required specialist work.

Security brought more tools and operational burden. The system was hard to see as a whole and harder to recover when a region or zone failed.

Customers thought in complete jobs: connect these environments, control what can communicate, survive failure, and understand the current state. Cisco needed one model for cloud networks, sites, routing, security, and operations.

Over several years, the team ran dozens of interviews and spoke with hundreds of IT administrators, cloud administrators, architects, and infrastructure specialists.

My networking background let me work directly with routing, BGP, security, and cloud experts. During technical reviews, I traced architecture decisions to the customer work they affected. We decided what customers needed to see, what the system could absorb, and what belonged in the product model.

I designed advanced connectivity and BGP flows in Figma and used them to resolve product decisions with Engineering. I led critique across the broader experience and kept executive reviews tied to real behavior in onboarding, connectivity, security, resilience, and operations.

Connections became the primary object. A connection described its source, destination, matched resources, security policy, and operating state. Customers could create cloud-to-cloud and cloud-to-site relationships while the product handled the underlying tunnels and routes.

We organized the rest of the experience around connections, multicloud regions, sites, and cloud networks. AWS, Azure, Google Cloud, Meraki, and Catalyst SD-WAN lived in one model. Onboarding followed the same logic across providers and network types.

The advanced connectivity work kept source and destination prominent while preserving route behavior, protocol, port, BGP, security, and visibility for experts. Tag-based connectivity reduced repetitive setup. Security and resilience lived inside the connection workflow.

Operators could see what was connected, how traffic would move, where policy applied, and whether the system could withstand a failure.

Hands-on

I translated routing, BGP, security, and cloud constraints into a product model organized around complete customer jobs. I designed advanced connectivity and BGP flows in Figma and worked directly with engineers and domain experts.

Leadership

I set the creative and experience direction, led critique, aligned the executive story to product behavior, and enabled the lead designer to carry the system through Public Preview.

The lead product designer owned the end-to-end experience, simplified onboarding and security integration, and stayed close to customers and Engineering through detailed design, QA, and handoff.

Product and Engineering built the underlying system. Cloud, routing, security, Meraki, Catalyst, and platform experts defined the constraints. Customers and partners challenged the model through interviews, co-development sessions, field conversations, and technical reviews.

Design ownership changed after Public Preview. My involvement ended with the phase shown here.

Cisco introduced Multicloud Fabric in Public Preview at Cisco Live 2026 with site-to-cloud and cloud-to-cloud connectivity, intent-based connections, per-connection security, and embedded visibility.

Across dozens of interviews and conversations with hundreds of practitioners, one leader at a hospitality company summarized the change:

"This completely changes how we'll create our cloud and site backbone. For the better."

The product gave teams one model for connecting clouds and sites, designing for failure, applying security, and understanding operational state. It replaced a stitched-together toolchain with a product customers could reason about as a system.

Technical fluency let me bridge a new networking domain with strong product design. I could work through routing constraints with engineers, give designers enough context to challenge the system, and simplify the experience without stripping away the controls experts needed.

Networking, security, identity, policy, health, remote access, and troubleshooting were spread across products. I started a two-to-three-year future-state direction alongside active delivery.

The Northstar organized the experience around the customer's world: sites, applications, users, devices, policy, health, and troubleshooting. The operating model followed that work across Cisco's internal boundaries.

Administrators had to translate one goal into separate configuration for sites, applications, users, devices, L3 and L7 rules, DNS, secure web gateway, identity, and IP ranges. End users dealt with certificates, office Wi-Fi, VPN, ZTNA, and authentication just to connect.

More than 35 people across Product, Engineering, TME, and Sales were working across two organizations and four cross-platform teams. The design needed to give them one product direction detailed enough to challenge, sequence, and build.

Research led customer interviews and synthesis in close partnership with me. We combined 24 early customer interviews with six workshops and working sessions involving more than 35 people across Product, Engineering, TME, and Sales. The work produced the vision and mission, personas, journey maps, design principles, a core use case, system models, and four end-to-end concepts.

A later policy study added ten one-hour interviews with a CIO, a CTO and chief architect, IT directors, security leaders, administrators, and network operators. Their organizations ranged from 201 to more than 10,000 employees.

The evidence changed the design. Smaller teams needed a safe common path. Experienced operators needed visibility into the underlying behavior and control over it. Source and destination moved earlier in the flow. Policy history became inspectable. Drafts, approvals, profiles, and team workflows became part of the model. Search favored exact matches.

The team kept migration, group lifecycle, device visibility, and cloud-to-device interaction open until Product and Engineering had an answer.

The Northstar defined policy through source, destination, and intent, then mapped those choices to L3, L7, DNS, secure web gateway, and IP controls. Profiles, drafts, approvals, history, and team workflows made each change accountable.

Policy testing exposed identity, group membership, matching rules, security checks, connection state, and the reason behind each result.

The end-user access concept selected certificate-based office Wi-Fi, ZTNA, or VPN from context. Secure Connect joined security, applications, remote access, sites, uptime, access rules, and ThousandEyes health data in the same operating model.

The model was modular. Teams could ship parts of it while keeping the larger product logic intact.

Hands-on

I created the Northstar product strategy and system model, completed the end-to-end interaction and visual design, and wrote production code for Secure Connect.

Leadership

I aligned 35+ people across two organizations and four teams, secured executive approval, and worked through architecture and sequencing with Product and Engineering. As the design team grew, I set creative direction and reviewed the flows where the experience could lose coherence.

Research led customer interviews and synthesis. Designers on the team carried the system into detailed product flows and developed policy visualization patterns that other Cisco teams later adopted.

Product and Engineering worked through architecture, feasibility, sequencing, and delivery. TME and Sales connected the product to the way customers bought and operated SASE.

Cisco Security teams owned the later Secure Access delivery. I carried the product model through the transition and stayed involved in critical experience decisions.

Jeetu Patel called the Northstar "fucking amazing." Leadership approved the direction, giving Product and Engineering a shared model for sequencing delivery.

I worked with Product and Engineering through the first customer and contributed production code. Cisco introduced Secure Connect in 2022.

Cisco attributes more than $100M in revenue to the wider SASE program delivered by me and my team. The figure covers the program as a whole.

Secure Connect later moved from Meraki into Cisco Security. Identity-led policy, policy visualization and history, testing, proactive health, troubleshooting, and team workflows continued to shape the direction for Secure Access.

The SASE Northstar taught me the value of design as an executive platform driver. It changed how Cisco could approach a new market, simplify the experience without reducing technical capability, and turn a future direction into a product teams could act on.

Writing code sharpened my judgment about product behavior and let me work with Engineering at the level where decisions were made. As the team grew, I applied that fluency through creative direction and critique. Later, I used AI to help designers develop code, interaction, and animation skills faster.