Project Info
Inspiration
Lexicon started from the problems we saw with browser agents. They inspect a screen or DOM, guess what to click, and repeat this for every step. It looks impressive, but it can be slow and fragile. A changed button, loading state, or hidden permission can break the workflow—or cause the wrong action. We wanted an assistant that works with the product’s real actions instead of operating it from the outside. What we built Lexicon is a TypeScript SDK that exposes product actions as typed capabilities. Each capability defines its inputs, route, handler, and confirmation policy. Gemini understands what the user means. Lexicon validates the request, collects missing fields, applies the product’s rules, and runs the real handler. Sensitive actions require confirmation in a separate user turn, so the model cannot approve its own request. We built Rillwork, a full Next.js product, to demonstrate it. It includes 32 capabilities across 9 routes covering analytics, customers, orders, invoices, approvals, settings, navigation, and exports. Challenges The hardest part was making confirmation actually trustworthy while keeping the conversation natural. We also worked through incomplete user requests, live-audio latency, microphone playback, and keeping the reusable SDK separate from demo-specific business logic.
What we learned
Browser agents are useful when no integration exists, but they have to infer how a product works from its interface. A capability-based agent gets a direct contract with the application. Our main lesson was simple: let the model understand intent, but let the product keep authority.
Lexicon
Give software a voice without giving the model unrestricted control.
Live demo · Project story · Built for OpenAI Build Week
Lexicon is a framework-agnostic TypeScript SDK that connects natural-language and live-voice interfaces to developer-owned product actions. Instead of asking a browser agent to inspect a screen and guess what to click, Lexicon gives the model an explicit map of routes, typed inputs, handlers, and confirmation policies.
The model interprets intent. Lexicon validates the request and enforces policy. The application keeps authority over execution.
Why Lexicon
Browser agents are useful when an application has no integration surface, but they operate from the outside. They repeatedly inspect pixels or DOM state, infer the next interaction, and hope the interface has not changed. This introduces latency and makes important workflows sensitive to layout changes, loading states, hidden permissions, and incorrect clicks.
Lexicon works from inside the product. A request such as “Create a customer named Northstar Labs on the Foundry plan” maps to a registered create-customer capability with typed fields and a real application handler. If the action is guarded, Lexicon prepares a preview and requires explicit confirmation in a later user turn before anything runs.
User request
↓
Gemini understands the intent
↓
Lexicon matches a registered capability
↓
Validate and collect typed inputs
↓
Apply direct or confirmation-required policy
↓
Run the application-owned handler
What is included
The repository contains two independent projects:
lexicon/
├── sdk/ # @lexicon/sdk — reusable capability runtime
└── demo/ # Rillwork — Next.js product using the SDK
@lexicon/sdk
- Serializable capability manifests
- Gemini function declarations
- Input coercion and required-field collection
- Guarded previews and later-turn confirmation
- Runtime handler registration and execution
- Typed Gemini and Live adapters
- Browser microphone PCM capture and gapless audio playback
- Deterministic local resolution for testing and fallback behavior
The SDK does not import React, Next.js, or the demo application. Authentication, data access, navigation, and mutations remain owned by the host product.
Rillwork demo
Rillwork is a complete Next.js application showing Lexicon across normal product workflows rather than a standalone chat window. The demo registers 32 capabilities across 9 routes, including:
- Analytics and navigation
- Customers, orders, and invoices
- Approval-required plan changes
- Settings, profile, and notification actions
- Filters, report exports, and live voice
- A capability console for inspecting routes, fields, schemas, and policies
Manual UI interactions and assistant interactions use the same application handlers, so voice does not create a second copy of the product’s business logic.
Safety model
Confirmation belongs to the Lexicon runtime, not the model. A guarded tool call creates pending state tied to the exact capability and normalized input. The model cannot approve its own request by returning a field such as confirmed: true; execution requires a separate user turn that matches the pending action.
Routine reads and navigation can remain fast, while sensitive writes receive a visible preview and explicit consent.
How Codex and GPT-5.6 were used
We used Codex with GPT-5.6 throughout Build Week as an engineering collaborator, not as part of Lexicon’s production runtime.
Codex helped us:
- Explore the capability-based architecture and pressure-test it against browser-agent failure modes
- Implement and refactor the framework-independent TypeScript SDK
- Build the Next.js demo, capability console, live-voice surface, and guarded-action UI
- Trace confirmation authority across multiple conversation turns
- Generate focused tests for validation, missing fields, cancellation, handler failures, and model self-confirmation attempts
- Review the package boundary so the SDK stayed independent from React and the demo
- Debug integration issues, improve accessibility and interaction polish, and prepare the project documentation
GPT-5.6 was especially useful for reasoning across the full system—model tools, runtime state, application handlers, and UI feedback—while Codex provided the repository-aware workflow for inspecting code, making changes, running tests, and validating the result. Product direction, safety boundaries, and final implementation decisions remained human-owned.
Lexicon itself uses Gemini for typed intent resolution and live voice. Codex and GPT-5.6 were the development tools used to build and evaluate the project.
Built with
TypeScript, Next.js, React, Node.js, Gemini API, Gemini Live API, Codex, GPT-5.6, Web Audio API, Tailwind CSS, and Vercel.
Run locally
Node.js 20 or newer is required.
Build the SDK:
cd sdk
npm install
npm run build
Run the demo:
cd demo
npm install
cp .env.example .env.local
npm run dev
Set LEXICON_GEMINI_API_KEY in demo/.env.local, then open http://localhost:3000.
On Windows, run:
powershell -ExecutionPolicy Bypass -File .\setup-windows.ps1
Validation
cd sdk
npm test
npm run typecheck
cd ../demo
npm run typecheck
npm run build
The SDK test suite covers manifest sanitization, tool generation, local resolution, missing-field collection, confirmation authority, cancellation, invalid inputs, handler failures, and serializable model responses.
Analysis
View
Metric
- 6
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- Next.jsIn code
- ReactIn code
- Tailwind CSSIn code
- TypeScriptIn code
- VercelClaimed
5 of 6 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
650 KB
Source files
52
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
Jalkarna/lexicon
79 files · 2.3 MB · @ b360954
Structure
Interface
33 files · 42%Screens, components and styles rendered to the user.
API & routing
3 files · 4%Request entry points: routes, handlers and controllers.
Application logic
13 files · 16%Domain rules, services and shared utilities.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- TypeScript58%
- CSS40%
- Markdown2%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
demo/package.json
npm · 34- @google/genai
- @lexicon/sdk
- @paper-design/shaders-react
- @radix-ui/react-scroll-area
- @radix-ui/react-slot
- @radix-ui/react-use-controllable-state
- @react-three/fiber
- class-variance-authority
- clsx
- framer-motion
- lucide-react
- motion
- next
- next-themes
- radix-ui
- react
- react-dom
- react-use-measure
- +16 more
sdk/package.json
npm · 33 development-only dependencies.
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.