Nick Bryant

Software.
Systems.
Worlds.

I build things from the first idea to the working product.
Explore the work ↘

Conceptual terrain study of an imagined generative world

01 / An engineering atlas

02Interactive work

Generative worlds

Games, authoring systems, and small experiments where procedural structure meets deliberate worldbuilding.

Conceptual landscape cross-section from desert mesas to alpine peaks
Concept study / Terrain, rules, inhabitation
The Lower Worlds project screenshot

01 / Field study

The Lower Worlds

Generative authoring · TypeScript / React / Three.js

An experimental generative-authoring system in TypeScript, React, and Three.js. Models and people define the world, schemas validate and version it, and deterministic rules run the game while player progress stays private.

Explore the architecture

The authoring stack separates intent, validated schema, versioned world definitions, and deterministic runtime state so generated content can remain inspectable.

System plate / 04

The Lower Worlds · architecture study

Illustrative assembly

An exploded isometric illustration of software architecture showing the intent, schema, world, and runtime layers of The Lower Worlds software architecture.

World. Versioned, reusable definitions preserve a coherent world across play.

Blind Magus project screenshot

03 / Field study

Blind Magus

Released action game · Independent

A released action game built around combining spells into new effects.

The Lower Worlds: Awakening project screenshot

06 / Field study

The Lower Worlds: Awakening

Creator and engineer · Playable prototype

A third-person dungeon adventure in Godot 4.7: prepare at Highbridge, explore the ruins below, and choose when to return to defend the garrison. Typed GDScript, physical puzzles, persistent progression, and rendered gameplay verification.

Chapter 02 / Applied intelligence

Agents &
systems

Local-first tools that make model work inspectable, bounded, and useful in the physical or commercial world.

Conceptual study of a speculative workshop machine
Conceptual study / Not actual hardware
AI Robot Workshop project screenshot

01 / Working system

AI Robot Workshop

Open source · Local-first agent workflow

Turns agent conversations into inspectable plans, firmware, parts records, bounded models, and bench observations. The documented hardware routes remain unbuilt.

Treasure Hunter project screenshot

02 / Working system

Treasure Hunter

Creator and engineer · Local agent system

A local, chat-operated marketplace agent that values every collected item, persists evidence and checkpoints, and explains its ranked results in a live dashboard.

Chapter 03 / Field notes

Writing from the work

Conceptual editorial study of embossed terrain and printing plates
Concept study / Ideas made durable
  1. Give Agents Lives, Not Just Jobs

    A1

    Give Agents Lives, Not Just Jobs

    Why I think ongoing pursuits, embodied experience, and a limited point of view can give agents something more interesting to say.

  2. A Small Model With a World Around It

    A2

    A Small Model With a World Around It

    What my local-model companion experiments taught me about structured output, useful conversation, and the architecture around a model.

  3. Human–Agent Interaction Is More Than Chat

    A3

    Human–Agent Interaction Is More Than Chat

    Presence, silence, interruption, and selective memory are part of the interface when an agent has a continuing life.

  4. Digital Twins Need More Than Your Chat History

    A4

    Digital Twins Need More Than Your Chat History

    A useful twin needs a history of changing views, explicit authority, and a distinction between representing someone and becoming its own agent.

  5. Marketing Is a World Agents Can Work In

    A5

    Marketing Is a World Agents Can Work In

    Lessons from SFV and SMBIN: content, audiences, campaigns, and feedback form an environment an agent can understand.

  6. Treasure Hunter

    01

    Treasure Hunter

    Building an agent that values every item and exposes its evidence, uncertainty, and resumable state.

  7. AI Robot Workshop

    02

    AI Robot Workshop

    From a plausible agent answer to persistent project files, explicit evidence, and a buildable path.

  8. Fractal Authoring

    03

    Fractal Authoring

    Building The Lower Worlds Online, and a world that can keep becoming more specific.

  9. Building procedural environments in Valenfeld

    04

    Building procedural environments in Valenfeld

    A practical look at shaping generated terrain into a world with authored intent.

  10. The Transformer Is the Transistor

    05

    The Transformer Is the Transistor

    A thesis on AI as a building block, and the verification and coordination infrastructure models need around them.

  11. The Lower Worlds: Awakening

    06

    The Lower Worlds: Awakening

    Building a home worth returning to: a playable Godot adventure, with in-engine screenshots and source.

Chapter 04 / About

Builder,
end to end.

Portrait of Nick Bryant

I’ve spent most of my career taking an idea and building the whole thing: the prototype, the product, and the team. Web, mobile, games, AR/VR, AI—I like learning what a hard problem needs and getting it working.

Right now I’m deep into agentic programming and generative worlds, trying to build things that weren’t practical a few years ago.

Denver / Boulder

Selected work

ARCOS / VN.AI

IP workflows · Next.js / Supabase / MongoDB / Redis / AWS

I led product engineering for IP management, permitted-use workflows, and content analysis. We connected roughly twenty model integrations and supported product pilots across the application and cloud stack.

Selected work

Procurement Sciences

B2B software · MERN / Python / FastAPI

I rebuilt an early Rails prototype as a MERN and Python/FastAPI product. I implemented the application, managed the engineering team, and hired the incoming CTO before the handoff.

Current · advisory

Investing systems

Investing / syndication · Co-founder, now advisory

I built investing and syndication software, AI-assisted underwriting workflows, investor reporting, and marketing automation for SMB Investor Network and Search Fund Ventures. My current role is passive advisory work.

2015–2020

Interesting Inventions

Consumer apps & games · Technical co-founder

Built and launched 5+ consumer applications through a holding-company portfolio, reaching nine-figure revenue scale.

Full career on the resume ↗
Cloud Versus Edge Is The Wrong Robotics Question
Cloud Versus Edge Is The Wrong Robotics Question project screenshot
All field notes

Published field note · Research note

· 5 min read

Cloud versus edge is the wrong robotics question

Place each robot operation by its deadline, data boundary, disconnect tolerance, and failure consequence instead of choosing one home for the whole robot.

Relay, a fictional mobile manipulator in a workshop tool crib, is closing a drawer when its wide-area connection disappears. The motor drive must keep current inside its limit. The local controller must finish or cancel the admitted motion. The perception stack may continue with reduced capability. A semantic planner can wait. Camera logs can remain on disk until the link returns. Asking whether Relay is “a cloud robot” or “an edge robot” gives one answer to five different failure problems.

Placement becomes useful only after the operation has a name. For each operation, ask four things: its latest acceptable completion time; the bandwidth or private data it consumes; how long it may tolerate disconnection; and what physical or operational consequence follows from lateness. Placement is the decision that follows from those constraints. It is not an identity assigned once to the machine.

Five-rung robot operation placement ladderA vertical five-rung ladder is read from bottom to top. The bottom rung is HARD LOCAL SAFETY / CONTROL, labeled microseconds to milliseconds and must survive disconnect. Above it are ON-DEVICE PERCEPTION, ON-DEVICE POLICY / SKILLS, NEAR-EDGE SERVICES, and ASYNC CLOUD ANALYSIS / TRAINING. Each rung names an increasing allowed-latency band and its behavior during disconnection, from continue locally or stop protectively at the bottom, through bounded fallback and queueing in the middle, to buffer and resume later at the top. Cobalt, cyan, coral, and lime markers distinguish authority, data movement, failure boundaries, and deferred work without relying on color alone.PLACE THE OPERATION / NOT THE ROBOTLOWER LATENCY / IMMEDIATE AUTHORITYHARD LOCAL SAFETY / CONTROLµs–msSURVIVE DISCONNECTON-DEVICE PERCEPTIONms–10s msLOCAL / DECLARED DEGRADEON-DEVICE POLICY / SKILLS10s–100s msBOUNDED FALLBACKNEAR-EDGE SERVICES10s ms–secondsEXPIRE / FALL BACKASYNC CLOUD ANALYSIS / TRAININGseconds–daysBUFFER / RESUME
Placement rises from hard local safety and control to asynchronous cloud learning as allowed latency grows and immediate dependence on connectivity falls.

A five-rung placement ladder

At the bottom, hard local safety and control owns current limits, watchdogs, protective stops, and fast stabilization. Its allowed latency is measured against the physical hazard, often microseconds to milliseconds, and disconnect behavior is “continue enforcing the local boundary or stop protectively.” Intrinsic’s technical specifications state a useful first-party boundary: its services do not override or replace robot-controller safety systems, and configured motion limits are not substitutes for the robot’s safety configuration. That is a vendor system boundary, not a comparative safety study.

One rung up, on-device perception handles observations whose age directly affects collision checking, localization, or grasp correction. It may use a camera, encoder, or local accelerator and operate within a millisecond-to-tens-of-milliseconds budget. If connectivity disappears, it continues locally, degrades to a declared sensor set, or withdraws the motion that depended on missing state.

Next, on-device policy and bounded skills can turn fresh observations into short action chunks or execute a validated trajectory. Their budgets may span tens to hundreds of milliseconds, but their output still passes local admission. Google DeepMind’s Gemini Robotics 2 announcement describes separate action, embodied-reasoning, and on-device model roles, including an on-device VLA intended for network-constrained operation. It shows one first-party model-family decomposition; it is not independent evidence that those models meet Relay’s deadlines or safety needs.

The fourth rung is near-edge service: a site server shared by several robots for heavier perception, map fusion, or policy inference. It can win when the site network has engineered tail latency, shared accelerators improve utilization, and every robot retains bounded fallback. A network partition should expire the remote lease or goal rather than silently extending it. Near-edge is remote compute with a shorter, observable failure path, not a synonym for local authority.

At the top, asynchronous cloud analysis and training receives logs, evaluates candidates, trains models, and prepares fleet updates. Seconds, hours, or days may be acceptable because no immediate actuator action waits for the result. Viam’s data-sync documentation describes local capture, buffering while offline, and resumed synchronization when connectivity returns. That is a concrete deferred-data pattern, not a fleet-reliability study; disk capacity, privacy, completeness, lineage, and rollout safety remain the operator’s work.

The strongest countercase is a controlled workcell with a private, redundant site network and a server that meets a measured deadline more reliably than a thermally constrained onboard computer. Placing perception or planning offboard may reduce robot heat, power draw, and hardware cost. The ladder does not say “closer is always safer.” It says that the offboard service must meet the operation’s deadline and partition contract, while hazards requiring faster independent enforcement stay below it.

What this does not prove

This note does not prove that cloud inference is unsafe, that on-device inference is deterministic, or that any cited vendor stack is production-validated for Relay. The five rungs are book synthesis, not an industry standard. They expose a reviewable decision: place each operation where its deadline, data boundary, disconnect behavior, and consequence of lateness can actually be enforced.

Which operation in your robot is placed by compute convenience today even though its failure consequence points somewhere else?

Open question

What I'm testing

Which operation in your robot is placed by compute convenience today even though its failure consequence points somewhere else?

Evidence boundary

Sources and boundaries

A linked source supports only its named role below. This note connects and tests ideas; the note itself is not evidence.

  • production report
    Google DeepMind Gemini Robotics 2 announcement

    First-party description of action, embodied-reasoning, and on-device model roles; it demonstrates one disclosed product-family split, not independent deployment validation.

  • official spec
    Intrinsic technical specifications

    States that Intrinsic services do not override or replace robot-controller safety systems; it defines a vendor boundary rather than comparing safety outcomes.

  • official spec
    Viam data synchronization documentation

    Documents local capture, offline buffering, and synchronization after connectivity returns; it is product behavior, not a study of fleet reliability or data completeness.

Back to all field notes