Exchange Bidding System

Portfolio, Ventures & What I Build

Product/systems design that turns AI tech into business results

I'm Gil, an AI Product Design Engineer. I take complex workflows and turn them into AI-native systems, from discovery through shipped product.

My north star is the complete practitioner: the idea that the best AI-native products are shaped by one mind that can hold design, engineering, and AI logic simultaneously, not handed off through layers of interpretation.

When the same person who defines the workflow also builds the prototype and wires the AI, translation loss disappears. Teams move faster and the gap between what we designed and what shipped closes.

What I Bring

Enterprise Systems

Enterprise End-to-End Systems Builder

I've designed complex product ecosystems at enterprise scale — multi-product platforms, multi-role workflows, and long-running transformation initiatives as a solo designer. Systems thinking, not just screen design.

AI Product Engineering

AI-Native Product Design Engineer

I design and prototype AI-native product systems — RAG pipelines, agentic workflows, human-in-the-loop interfaces, structured outputs, and context-aware products. AI product work grounded in real systems, not demos.

Education & Evangelism

Technical Educator & Evangelist

I help people understand, adopt, and build with new technologies — through demos, workshops, tutorials, and product systems thinking. Teaching as adoption; adoption as product design.

A consistent practice across technology cycles

Tech Speaker Microsoft · 5,000+ developers

Co-founder 8th Light · Digital transformation

Startups + Enterprise Engine Yard · ThoughtWorks · Dev tools

Founder Skowak · Design engineering · Teaching

Enterprise Focus SunPower · Digital transformation · Ecosystems

AI Eng Focus Craftal · CareDash · Multi Agent Systems

Now Contextus · Craftal v.2 · AI-native systems

How I Work

I don’t start with AI. I start with how work actually happens.

The method works in cycles. Each one scoped small enough to prove value fast, wide enough to compound across the whole system.

Each cycle makes the next one faster, safer, and more valuable. Real workflows before AI use cases. No baseline, no proof. No proof, no scale.

01 — 03

Understand

Discover
Model
Baseline

Know before you build

04 — 06

Intervene

Design
Adapt & Script
Measure

Build small, prove value

07 — 08

Promote

Promote
Orchestrate

Make it durable and connected

09 — 10

Scale

Govern
Reuse & Expand

Govern and compound

Where most AI projects break down

Most AI failures aren't technical. They're structural: siloed teams, AI built without real workflows, ideas that can't survive contact with production. The method closes those gaps.

Design, engineering, and AI in separate rooms

Work lands in three different hands. Every handoff is a translation, and translation is where ideas lose fidelity.

One practitioner across all three layers

I lead design, write code, and wire the AI as one strategic partner across all three disciplines. No handoffs, no interpretation layers, no gap between what was designed and what shipped.

AI built without a workflow to plug into

Teams rush to launch LLM features with minimal ROI. Without mapping real workflows or solving real problems, the result is unused chatbots and shallow automation.

Bridge between LLMs and real work

I map how work actually happens first, then wire the AI stack into those real decisions. The result is automation that runs, not a chatbot no one uses.

Technical Toolkit

The full stack, from workflow model to deployed AI system.

My stack spans the full system: AI engineering (OpenAI & Anthropic APIs, LangChain, LangGraph, DSPy, RAG pipelines, vector stores, structured outputs, agent orchestration), frontend and prototyping (React, Angular, Vue, TypeScript, API-connected interfaces), backend and tooling (Python, FastAPI, Rails, PostgreSQL/pgvector, Docker), and product and design (systems modeling, workflow mapping, information architecture, interaction design, design engineering).

As a product generalist, I choose the right tool for each layer (design, front end, data, or model) so ideas travel from workflow model to shipped system without unnecessary handoffs.

Getting personal

Things I do when I'm not building

Still-life sketching, coastal hiking, PC teardowns, and slow travel through cities with good architecture.

I draw to stay sharp. I travel to stay curious. I take things apart to stay honest about how they work.

Back

Exchange Bidding System

An account management system that clarified user roles, carrier access, and permissions across an insurance bidding platform.

Skills applied:

Visual Design Interaction Design Prototype Dev Research Information Arch

The Exchange Bidding System needed more than quote comparison. It also needed a reliable way to manage the people and organizations participating in the exchange: internal admins, exchange agents, carriers, and carrier-specific accounts.

I designed the Accounts Management tool as the administrative foundation for the exchange. It gave Fidelity Life teams a clear way to manage user permissions, carrier records, contact information, underwriting contacts, and role-specific access across manual and automated bidding workflows.

The Problem

Multi-carrier workflows break down when permissions are unclear.

The Exchange Bidding System depended on multiple roles working together. Internal admins needed platform access. Exchange agents needed permissions to select offers, update carrier status, process closeout, or work in read-only mode. Carriers needed structured records, contact details, underwriting information, and assigned accounts.

Without a clear management layer, the exchange risked becoming fragile. A user could have too much access, too little access, outdated carrier information, or unclear responsibility for a specific workflow step.

The problem was not just account creation. It was operational control.

diagram bidding accts 01 — Unclear account ownership created permission risk across the insurance exchange.

Solution

A structured admin layer for people, carriers, and access rights.

I designed the tool around three administrative views: Admin Accounts, Agent Accounts, and Carriers. Each view used a clear table layout so teams could scan records quickly and understand who had access to what.

fidelitylife exchange acc mgt 01 — Admin Accounts showed internal users and their platform-level permissions.

The Admin Accounts view gave Fidelity Life a simple permission matrix. Teams could see whether a user had access to Admin, Carriers, Carrier Accounts, or Exchange Accounts. This made access review easier because permissions were visible directly in the table.

fidelitylife exchange acc mgt 03 — The edit modal made admin permissions explicit and easy to update.

Instead of burying permissions in a complex settings page, account editing happened in a focused modal. This kept the workflow fast while reducing the chance of changing unrelated account details.

diagram bidding accts 02 — Accounts Management acted as the control plane for exchange access.

The Agent Accounts view focused on what exchange agents could do inside the bidding workflow.

fidelitylife exchange acc mgt 04 — Agent Accounts exposed workflow-specific permissions for exchange users.

Permissions were tied to operational actions, not generic roles. Agents could be allowed to select carrier offers, update carrier status, process closeout, or work in read-only mode.

fidelitylife exchange acc mgt 05 — Agent permissions mapped directly to bidding workflow responsibilities.

This pattern helped make permissions easier to reason about. Instead of asking whether someone was “an agent,” the system asked what that person was allowed to do in the exchange.

Outcome

Better operational control across the exchange ecosystem.

The Accounts Management tool created a clearer foundation for the Exchange Bidding System. It helped internal teams manage who could access the system, what agents could do, and how carrier information was maintained.

fidelitylife exchange acc mgt 07 — The Carriers view organized insurance partners by rating and carrier type.

Carrier management was especially important because the exchange depended on accurate carrier data. The table made it easy to scan carrier names, A.M. Best ratings, and whether a carrier was primary or secondary.

fidelitylife exchange acc mgt 08 — Carrier detail pages grouped contact, underwriting, and account information.

The carrier detail view turned each carrier into a structured operational record. Teams could manage general contact information, new business contacts, underwriting contacts, and assigned carrier accounts from one place.