Product design for complex systems

AI · data · fintech

I turn complex systems into decisions people can understand and act on.

Silo — from markets to managed lending

A lending product where people choose the risks they fund.

From choosing an individual market to managing capital and working through a personal agent. This case shows how the user journey evolved as the product developed: first, we needed to make basic actions clear, then support complex strategies and delegation, and later enable agents to prepare actions.

About Silo

Silo is a lending protocol: participants supply assets for lending or borrow against collateral. Separate markets let them choose their collateral exposure—the assets and associated risks they are willing to fund.

This freedom creates complexity. Participants need to compare terms, choose a suitable market, open a position, and understand how to manage it. My work focused on turning this mechanism into a complete user journey. In this case, I examine three connected design decisions: different levels of interaction with markets, delegation of capital allocation, and agent-assisted flows with user review and signing.

A–B — From a working MVP to composed strategies

We started with an MVP that let users perform the core actions in an individual market. This version helped us validate that the basic journey worked. The next question emerged as we moved from a single operation to a strategy: how could we preserve control over the terms while reducing manual work?

Problem — More control creates more work

Isolated markets expand the available choices, but place some of the work on the participant. They need to weigh yield, risk, available liquidity, and the terms of each action. When working across several markets, this effort repeats.

The product therefore needs to help people use the level of control they need: perform a straightforward action quickly or prepare a more complex strategy. Comprehensive information is useful only when it helps someone make a decision.

The initial growth in assets accompanied the MVP; a more pronounced increase occurred during the development of multi-action features. This is useful context, but the timing alone does not establish the contribution of any particular change. In a small project with too few users for a reliable A/B test, separating the effect of the interface from other factors is especially difficult.

To evaluate the solution, it is useful to separate two questions: how many actions the user journey requires, and how the amount of capital in the protocol changes. The illustration below compares shorter journeys with asset trends in Simple and Power scenarios.

From sequence actions to multi-market actions

In the original version, a complex strategy was built from separate, sequential actions. The user repeatedly selected a market, prepared an operation, and reviewed its terms. Multi-market actions connected this preparation: users could work with several markets in one flow and see the position their chosen actions would create.

Decision — Different scenarios, one product model

A simple deposit and a composed strategy require different levels of interaction. The key distinction was the user's task, rather than the size of their wallet.

For the simple scenario, the solution centers on a one-sided market view, essential terms, and a clear outcome for the action. For the composed scenario, it centers on comparison, position simulation, and preparing operations across markets. A shared model of positions and risk connects these journeys.

The product decision was to offer different levels of control while keeping the transition between scenarios understandable. The priority is to provide capabilities that help users choose, prepare, and review an action; additional data and automation should support that task.

One important tradeoff is that preparing several operations does not guarantee execution in a single transaction. The interface needs to make the work easier while preserving necessary confirmations and visibility into the consequences.

Result — Less repeated work, more control over the strategy

The user journey came to support both a quick action and the preparation of a composed strategy. For the complex scenario, the key change was a connected way to work with markets and the resulting position; for the simple scenario, it was access to essential terms without having to go through every setting.

The behavioral comparison illustrates the effect we wanted to achieve: fewer repeated actions while preserving control. However, the observed relationship could be a correlation or a coincidence. With a small user base, it is difficult to make a reliable comparison and establish whether a feature caused the observed change.

During the development of multi-actions, the volume of assets initially grew and then declined. This trend does not establish that a shorter user journey is sufficient for sustained protocol growth. The next product question concerned the way capital itself was allocated.

C — Make delegated capital management usable

Problem — Different participants need different control

The protocol still consisted of separate markets. For participants who simply wanted to deposit funds, choosing markets independently and continually reallocating capital remained a complex task.

Professional teams had a different need: to create markets with their own terms, deploy large volumes of assets, and distribute liquidity between them quickly. This required more management capabilities.

Vaults connect these needs. One participant chooses the terms of delegation, while another manages capital allocation within defined limits. I therefore treated the depositor experience and the manager experience as two connected user journeys.

Decision — Make delegation a distinct experience

Managing every operation independently and delegating capital allocation are different needs. Vaults allow the offering to be built around the second scenario: the depositor chooses a vault and its participation rules, while the manager handles allocation within the permitted limits.

This changes what the user chooses. They evaluate not only an individual market, but also the manager, potential exposure, and withdrawal terms. A simple entry point needs to help them understand these differences.

Direct markets remain valuable for people who want to choose their exposure independently. The vault experience adds another way to participate. The key tradeoff is to reduce the operational burden while keeping the essential terms of delegation visible.

Attracting capital also depends on economics, incentives, and ecosystem partnerships. The user experience needs to make the offering usable; protocol growth comes from several areas of the team's work.

Result — A new way to place and manage capital

Depositors gained a journey centered on choosing a vault and its terms; managers gained tools for allocating and reallocating liquidity. Companies could work with large asset allocations, while users could delegate some operational decisions.

The chart shows strong growth in protocol assets after vaults were introduced. This is consistent with the direction of the product change, but it does not allow all of that growth to be attributed to the interface or a single feature: market conditions, incentives, and partnerships also mattered.

D — From app UX to agent-assisted UX

Problem — Product advantages became harder to reach

After the peak, the protocol experienced an outflow of users and capital. The team associated this with changing market conditions and growing pressure from major competitors, which began offering similar capabilities. Risk isolation was no longer a unique advantage for Silo.

Some advantages remained: individual markets continued to offer attractive terms. But finding and using them required a complex journey of comparison and action preparation. The scale of larger platforms intensified competition: greater liquidity and trust helped them attract new capital.

We looked for additional ways to access the product. Growing API usage by aggregators and agents, along with interest in personal agents, informed the next hypothesis: users could describe a financial task, and an agent could find suitable opportunities and prepare a strategy through the API and MCP. Reviewing the terms and signing transactions would remain the user's responsibility.

This shift required more than providing an API to an agent. Without a visual representation, users find it difficult to review a composed solution. An agent may choose the wrong sequence of actions, and different LLM models may interpret the same instructions differently. We needed to design and test the entire journey from a request to a proposal that a person could evaluate.

Decision — Let the agent prepare, let the user review

We built an MCP server on top of our API and began adapting personal agents for agent-first UX. The agent retrieves Silo data, compares opportunities, and prepares actions. The user reviews the proposed strategy and signs transactions with their wallet.

I ran extensive tests to validate working scenarios: how the agent understands the task, selects tools, and builds a path to action. The focus was on alignment between the user's intent, the prepared operations, and the outcome the person would need to review.

To support proposal review, we added the ability to display predefined interface components: charts, tables, and information blocks. The agent can assemble them for a specific request and focus attention on the terms of the chosen action. This gives users visibility into information that was previously spread across several application screens.

Below is an example of this interaction: a request to deposit funds, the agent's proposal, key vault parameters, and data to review them.

Result — A reviewable path from intent to action

This stage produced an MCP server built on the API, validation of working scenarios, and visual components for evaluating agent proposals. We explored a journey in which the user sets a goal, the agent takes on part of the search and preparation, and the decision and signing remain with the person. The impact of this direction on attracting capital has yet to be evaluated.

The common thread in my work is helping people use the capabilities of a complex system at the depth they need: perform an individual action, build a strategy, delegate management, or review an agent's proposal.