HowToPC

An agent-native PC configurator where people and AI build the same PC together without sacrificing compatibility or trust.

Comment

Inspiration

Building a PC looks like shopping.

In reality, it is a constraint problem.

A CPU determines which motherboard sockets are valid. A motherboard determines memory type, expansion capacity, and storage resources. A GPU needs enough power, the right connections, and enough physical clearance. A cooler needs the correct socket and enough room inside the case.

One component can quietly invalidate several others.

Our starting question was simple:
What if an AI could help build a PC without becoming the authority on whether the hardware actually works together?

Most AI assistants sit outside the configurator. They can recommend parts, describe what buttons to click, or attempt to understand a page through browser automation.

That creates an awkward divide:

Traditional AI assistant HowToPC with WebMCP
Reads or scrapes the interface Reads structured application state
Guesses what actions are possible Uses explicitly registered tools
Maintains its own idea of the build Shares the real builder session
Can suggest incompatible changes Mutations pass deterministic checks
Needs UI automation Calls semantic application capabilities

WebMCP gave us a different model.

Instead of teaching the agent how to operate HowToPC, we made HowToPC itself explain what it can do.

The result is a configurator where the human and the agent can alternate control of the same build while deterministic application logic remains the final authority.

The AI proposes. HowToPC verifies. The person stays in control.

What it does

HowToPC is an agent-native PC configurator that combines a traditional hardware builder with structured WebMCP capabilities.

A person can browse a large sourced component catalog, assemble a computer, inspect compatibility, monitor motherboard resources, and visualize the configuration through a parametric Digital Twin.

At the same time, an AI agent can work with that exact same configuration.

For people

HowToPC provides:

  • 26,415 sourced hardware products
  • CPU, motherboard, memory, GPU, storage, PSU, case, cooler, fan, and networking categories
  • searchable catalog filters and compatibility-aware discovery
  • RTX 4060 Gaming PC and High-End Gaming PC starter templates
  • deterministic compatibility checks
  • DIMM, M.2, SATA, PCIe, and other resource accounting
  • GPU length and CPU cooler clearance checks
  • modeled component collision detection
  • a real-scale parametric Digital Twin
  • explicit UNKNOWN states when reliable geometry or topology is unavailable

For agents

The same page exposes 10 structured WebMCP tools:

WebMCP tool Capability
builder_get_state Read the current PC configuration
catalog_search Search the sourced hardware catalog
catalog_inspect_product Inspect structured component specifications
builder_add_product Add a component
builder_remove_product Remove a component
builder_replace_product Replace an installed component
builder_compatibility_report Request deterministic compatibility diagnostics
builder_resource_usage Inspect consumed and available hardware resources
builder_geometry_diagnostics Inspect physical clearances and modeled collisions
builder_find_compatible Search for hardware compatible with the current build

The important part is not simply the number of tools.

It is that they operate on the same canonical builder session used by the visible interface.

If a person changes a component, the agent immediately sees it.

If the agent replaces a component, the person immediately sees it.

There is no hidden "AI version" of the PC configuration and no synchronization layer trying to keep two builds aligned.

Compatibility remains deterministic

The language model does not decide whether two components are compatible.

For example, if an agent attempts to install an Intel LGA1700 motherboard into a build containing an AMD AM5 CPU, the mutation is rejected by HowToPC's transaction and compatibility logic.

CPU socket does not match motherboard.

That same protection applies whether the requested change came from a person or an agent.

Unknown is not compatible.

When HowToPC does not have enough evidence to verify something, it reports that limitation rather than fabricating confidence.

How we built it

HowToPC is a TypeScript monorepo built around a separation between product data, engineering rules, application state, geometry, and agent capabilities.

Architecture

                ┌───────────────────────┐
                │       Human UI        │
                │  Parts / Build / Twin │
                └──────────┬────────────┘
                           │
                           ▼
                ┌───────────────────────┐
                │ Canonical Builder     │
                │       Session         │
                └──────────┬────────────┘
                           │
              ┌────────────┼─────────────┐
              ▼            ▼             ▼
       Compatibility   Resources      Geometry
          Engine       Accounting      Engine
              ▲            ▲             ▲
              └────────────┼─────────────┘
                           │
                ┌──────────┴────────────┐
                │      WebMCP Tools     │
                │   AI agent actions    │
                └───────────────────────┘

Both interfaces converge on the same state and the same validation logic.

Sourced hardware catalog

We normalize a pinned snapshot of BuildCores OpenDB into deterministic product records.

The public catalog contains:

Source Products
Normalized BuildCores products 26,408
Curated sourced references 7
Total public catalog 26,415

Catalog searching, facets, compatibility filtering, and pagination happen against the full data set rather than a small demo fixture.

Deterministic compatibility

Compatibility is handled outside the language model.

The rules cover areas including:

  • CPU and motherboard sockets
  • memory generation
  • motherboard and case form factors
  • CPU cooler socket support
  • GPU and case clearance
  • motherboard resource consumption
  • installed quantities
  • PSU and component requirements
  • compatibility-aware builder transactions

An agent can request a change, but it cannot bypass these rules.

Parametric Digital Twin

We also built a geometry layer that converts known hardware dimensions into a real-scale parametric preview.

The system can reason about values such as:

GPU length
CPU cooler height
Case internal limits
Modeled component volumes
Component collisions
Mount topology

We deliberately avoid presenting the Twin as manufacturer CAD.

If exact mounting geometry is not sourced, the application says so.

That makes the model less visually magical, but much more trustworthy.

WebMCP bridge

The WebMCP implementation registers tools through the browser's native model context surface.

Conceptually:

document.modelContext.registerTool({
  name: "builder_find_compatible",
  description: "Find products compatible with the current PC build",
  // structured input schema
  // deterministic application handler
});

The important architectural decision was to reuse existing application services.

We did not create separate AI-only compatibility rules, a separate agent catalog, or a parallel builder state.

Engineering confidence

The project currently has:

53 test files / 182 automated tests

Coverage includes:

  • catalog ingestion
  • normalization
  • catalog searching
  • compatibility rules
  • quantity transactions
  • resource accounting
  • geometry
  • collision detection
  • starter templates
  • API routes
  • canonical builder sessions
  • WebMCP registration
  • WebMCP tool behavior

The starter templates also have regression gates requiring them to remain both deterministically compatible and free from modeled component collisions.

Challenges we ran into

1. Deciding where AI reasoning should stop

The easiest implementation would have been a tool like:

change_my_pc_build(prompt)

That would also have been the least interesting architecture.

It would make the language model responsible for interpreting hardware constraints and deciding whether its own proposed changes were valid.

We wanted a stronger boundary.

The model can decide what it wants to try.

HowToPC decides whether the requested transaction is allowed.

That separation became one of the most important design principles in the project.

2. Working with incomplete real-world hardware data

Real hardware catalogs are messy.

Some components have detailed measurements. Others omit dimensions, connector topology, mounting coordinates, or other fields required for exact mechanical reasoning.

We had a choice:

  1. invent reasonable-looking values
  2. make uncertainty visible

We chose the second option.

For example, if exact PCIe slot topology is unavailable, the Digital Twin can use a standardized parametric position for visualization while separately reporting that the exact topology is unknown.

Similarly, if an AIO cooler has known radiator dimensions but no reliable case mounting coordinates, we do not invent a radiator location.

Missing data is treated as information, not an invitation to hallucinate.

3. Making the Digital Twin honest and useful

A visually convincing 3D scene can create false confidence very quickly.

During development, our starter builds exposed a good example.

The original GPU choices created GPU and PSU intersections under the standardized parametric placement model.

Instead of hiding the warning, we treated the visual problem as a real acceptance failure.

We replaced the GPUs with thinner models that preserved the intended performance tiers and added automated regression checks so the starter builds now require:

Compatibility: PASS
Modeled collisions: 0

That gave us a useful rule for the rest of the product:

If the Twin claims something physically intersects, a starter template should not ship until we understand why.

4. Keeping the human and agent truly synchronized

It is easy to demonstrate an AI modifying a special test object.

It is harder to make the AI participate in the exact same stateful application that the human is using.

We had to make sure WebMCP tools register once while still reading the latest builder session.

That allows this sequence:

Human changes GPU
        ↓
Agent reads new GPU
        ↓
Agent replaces motherboard
        ↓
Human UI immediately reflects motherboard
        ↓
Human continues editing

No page scraping. No reloading agent context. No second copy of the build.

That shared-state loop became the core of the project.

Accomplishments that we're proud of

WebMCP is part of the product architecture

We are especially proud that WebMCP is not just a hackathon panel attached to the side of HowToPC.

The tools are backed by the same catalog, session, compatibility, resource, and geometry systems used by the application itself.

That means the agent receives real capabilities rather than privileged demo shortcuts.

26,415 sourced components

The configurator operates on a genuinely broad normalized catalog instead of a handful of carefully selected demo products.

That forced our search, compatibility, and WebMCP architecture to work with arbitrary hardware rather than known fixtures.

A shared human and agent workspace

The most important UX achievement is simple:

There is only one build.

The person can take control.

The agent can take control.

Then the person can take control again.

Every participant sees the state produced by the previous action.

Deterministic safety boundaries

A language model cannot simply talk HowToPC into accepting incompatible hardware.

Agent mutations go through the same deterministic validation path as human mutations.

An honest Digital Twin

We built geometry visualization that distinguishes between:

  • sourced measurements
  • parametric placement
  • verified clearance
  • modeled collision
  • unknown topology

That distinction matters to us because an engineering interface should communicate what it knows, not just what it can render.

What we learned

WebMCP changes browser automation into application interaction

Traditional browser agents often need to infer application semantics from text, layout, buttons, and DOM structure.

WebMCP turns that relationship around.

The website can explicitly say:

Here is how to read the build.
Here is how to search products.
Here is how to inspect hardware.
Here is how to request a replacement.
Here is how to verify compatibility.

That is a much cleaner contract between an application and an agent.

Better agent tools encourage better software boundaries

Designing WebMCP tools forced us to think carefully about where responsibilities belong.

builder_find_compatible should search.

builder_replace_product should request a mutation.

The compatibility engine should validate it.

The builder session should commit it.

The UI should render the result.

The language model should not secretly own all five responsibilities.

Structured uncertainty is powerful

One of the most useful ideas in HowToPC ended up being:

Unknown is not compatible.

AI systems are extremely good at making incomplete information sound complete.

An engineering tool needs the opposite instinct.

If the application cannot verify a physical mount, resource limit, or compatibility relationship, that uncertainty should survive all the way into the UI and the agent response.

Human and agent interfaces do not have to compete

We initially thought about WebMCP mainly as a way for an AI to operate the configurator.

The more interesting result was realizing that the human interface and agent interface can complement each other.

Humans are good at subjective choices:

  • aesthetics
  • brand preference
  • deciding between several good options
  • exploring the 3D configuration

Agents are good at repetitive structured work:

  • catalog searching
  • comparing specifications
  • checking constraints
  • identifying compatible alternatives
  • summarizing complex state

A shared session allows each side to do what it does well.

What's next for HowToPC

The challenge build proves the core architecture, but there is a lot more we want to explore.

Richer mechanical topology

Future versions could incorporate more sourced manufacturer geometry, including:

  • exact PCIe slot positions
  • radiator mounting locations
  • fan locations
  • drive cages
  • cable clearance
  • motherboard headers
  • GPU power connector clearance

That would allow the Digital Twin to evolve from a parametric verification aid into a much deeper mechanical planning system.

Smarter build optimization

WebMCP opens the door to agent workflows such as:

"Build the fastest gaming PC possible under my power and size constraints."

"Reduce the cost of this configuration without changing the GPU."

"Make this build quieter while preserving performance."

"Find the smallest case that can safely fit everything I already selected."

The important part is that these optimizations could still operate through deterministic HowToPC constraints rather than model intuition alone.

Regional retailer and pricing support

The architecture already separates product identity from merchant offers.

A future version could layer regional availability and pricing on top of the sourced component model while keeping compatibility independent from temporary store data.

Saved and shareable builds

We would like builders to create persistent configurations that can be:

  • shared with friends
  • opened by an agent
  • compared against alternatives
  • versioned over time
  • converted into upgrade plans

From PC builder to PC engineering assistant

The long-term idea is bigger than recommending parts.

We want HowToPC to become a structured environment where a person and an AI can reason about a computer together.

The person brings intent.

The agent brings speed.

The catalog brings evidence.

The compatibility and geometry engines bring constraints.

And WebMCP connects all of them.

HowToPC is our experiment in what happens when an AI does not merely talk about an application, but becomes a safe participant inside it.

Built With

Share this project:

Updates

Submission history