ElijahOS

Portfolios are built for one visitor. ElijahOS gives the second one, your agent, typed WebMCP tools to search evidence and act inside the same OS a human is exploring.

Comment

Inspiration

I rebuilt my portfolio for a web where every visitor brings an agent.

ElijahOS already existed as a personal website with two human interfaces: a windowed desktop OS and an intentional one-app-at-a-time mobile shell. But like most portfolios, it was still designed for one participant. A visitor could browse it, or an outside agent could summarize rendered text, but the agent could not reliably understand the site's capabilities, distinguish evidence from presentation, or act inside the same interface the person was using.

That felt like the right problem for WebMCP. Instead of adding another chatbot, I wanted the website itself to become natively operable by the visitor's agent while the human experience remained intact.

What it does

ElijahOS now gives each participant the interface it needs:

  • The person explores a playful personal operating system, opening apps, arranging windows, reading projects, and controlling the music player.
  • Their agent receives ten narrow, typed, page-scoped WebMCP capabilities over the same public content and live workspace.
  • Both operate on shared, visible state. Agent actions appear inside Agent Workspace, and bounded human changes can be read back through a workspace-state tool.

A visitor's agent can bring in a distilled, session-only objective; search and inspect evidence; surface unsupported terms instead of guessing; and compose the actual ElijahOS apps that show the selected material. The person can inspect the sources, edit or clear the objective, change the workspace manually, and remain the decision-maker. The agent can then continue from a narrow snapshot of that human action.

The site does not generate fit scores, rankings, hiring verdicts, or automated recommendations. It supplies candidate-authored evidence, provenance, contribution scope, limitations, and documented gaps. The visitor or their agent performs the interpretation.

Why WebMCP is essential

This is more than machine-readable portfolio data. The core experience is coordinated action inside a page both participants can see and change.

Static metadata can describe content, scraping can recover text, and a detached API can return records. None of those creates the same page-local handoff: the agent can make its objective visible, investigate typed evidence, place the supporting artifacts into the existing UI, let the person redirect the workspace through ordinary navigation, and then resume from bounded shared state. WebMCP turns the website from something an agent merely reads into an environment the visitor and agent can use together.

The normal interface remains fully usable without WebMCP. The capability surface is progressive enhancement, not a replacement for the site.

How I built it

ElijahOS is built with Next.js 16, React 19, TypeScript, Zustand, Three.js, and Vercel. One client-side provider registers ten tools through the browser's available ModelContext host after the shell becomes interactive.

Five tools carry the core journey: set_visit_intent, search_evidence, inspect_evidence, compose_workspace, and get_workspace_state. Three read-only tools expose the public profile, resume, and contact data. Two visible action tools open an allowlisted app and control the on-page music player.

The WebMCP adapter is isolated in src/lib/webmcp. It detects the available browser host, validates narrow JSON-schema inputs, uses accurate read-only and untrusted-content annotations, returns structured failures, and records each call in an in-memory activity feed. It has no database, analytics, provider credential, persistent query log, or server-side agent.

Evidence is derived from the same typed sources that render the public portfolio rather than maintained as a second biography. Each record includes a canonical route, authorship provenance, documented contribution scope, limitations, displayable app artifacts, and first-hand links where available. Workspace actions reuse the existing app registry, shell-neutral launcher, desktop window store, and separate mobile opener.

What people and agents can now do together

Previously, a person could navigate ElijahOS while an external agent reasoned in a separate conversation. The agent could summarize the page, but it could not reliably know what the person had opened, place the exact supporting artifacts into the OS, or make its objective visible inside the site. DOM automation was especially brittle against overlapping windows, focus state, minimization, anchored project sections, and the separate mobile shell.

Now the agent can investigate the structured evidence and visibly compose a workspace. The person can verify each claim in context, review the activity feed, change the workspace by hand, and hand control back without exposing the rest of their private conversation. That agent action → human correction → agent continuation loop is the collaboration WebMCP unlocked.

Challenges I faced

The hardest part was preserving ElijahOS instead of flattening it into a recruiter dashboard or a chat transcript. Every capability had to pass through existing app and shell boundaries so desktop and mobile behavior stayed coherent.

The second challenge was trust. Portfolio claims are easy to overstate, so I designed the evidence layer to preserve sources, contribution scope, limitations, and explicit unmatched terms. “No documented evidence on this site” had to remain a useful result rather than a gap for a model to fill creatively.

The third challenge was verification across an experimental browser surface. I kept source tests, injected-host browser tests, native discovery, deployed execution, and model-selection claims separate. A successful HTTP response is not WebMCP proof, and deterministic Playwright coverage is not proof that every agent will choose the same tools.

What I learned

I learned that a good agent interface is less about exposing everything and more about designing a small set of semantic capabilities with honest boundaries. Visible, reversible actions build more trust than invisible automation. Structured uncertainty is a feature. And a shared workspace only works when both sides can understand what changed without transferring the person's entire private context.

Most importantly, WebMCP changed how I think about personal websites: the human interface can stay expressive while an agent receives a completely different native interface over the same state.

Challenge provenance

ElijahOS predates the challenge. The public challenge-baseline tag preserves the sanitized pre-challenge desktop/mobile OS, app system, public portfolio content, and original Ask concept. The meaningful post-baseline work includes the WebMCP adapter, ten-tool surface, typed evidence projection, session-scoped visit intent, shared workspace bridge, Agent Workspace and activity feed, anchored evidence navigation, focused tests, public release documentation, and the separately deployed challenge edition.

Try it

Open https://webmcp.elijahos.com in ChatGPT's in-app browser or Chrome with WebMCP enabled. No account or credentials are required. The complete MIT-licensed source and testing instructions are available at https://github.com/juulsverne/elijahos-webmcp.

Built With

Share this project:

Updates

Submission history