You make Jack do more real work, more reliably.
The agent is the product. Your job is to make the underlying harness stronger: execution, tools, memory, context, evaluation, reliability, and the loop where the system checks its own work before a customer has to.
If you have never built or seriously modified an agent system, this will feel unfamiliar. If you already use AI-assisted development as your default way of working, you will have the right instincts for the pace.
A typical week is closer to systems research infrastructure than feature work.
You will spend most of your time building the shared substrate that lets Jack own work: isolated execution, reproducible environments, reliable state, semantic memory, retrieval, tool orchestration, evaluation harnesses, and permission boundaries.
Some days are product architecture. Some days are live-system reliability. Some days are making employee environments faster to build, easier to inspect, and safer to update without losing learned state. The common thread is continuity: Jack has to show up tomorrow with the same context it learned today.
The work is full-stack, but mostly at the systems layer.
Jack is not just a UI over a model. There is a distributed systems problem underneath: isolated long-running workers, durable state, retrieval-heavy context, tool orchestration, environment reproducibility, observability, recovery, and safe human oversight.
A lot of the work is infrastructure shared across employees and environments: making containers and bootstrap paths faster, making syncs deterministic, automating quality checks, preserving local state across upgrades, and turning messy live failures into repeatable tests.
The important question is rarely “can the model call this API?” The important question is whether the system can repeatedly move from intent to action while preserving context, isolation, observability, and a clean handoff back to a human when uncertainty is high.
Context is a core system, not a prompt trick.
A real AI colleague needs a structured understanding of people, projects, preferences, files, conversations, tools, and decisions. That means building memory architectures, semantic indexes, knowledge graphs, retrieval pipelines, and evaluation loops that keep context useful without making it noisy or unsafe.
This work sits between research and infrastructure. You need enough taste to know what the model should see, enough systems judgment to make retrieval reliable, and enough product judgment to preserve trust when memory is incomplete.
We expect high agency and careful speed.
We are early, so the work changes shape quickly. You should be comfortable moving from a customer request to a live-system diagnosis to a production patch without needing every boundary prewritten.
We care about speed, but not theater. Good work here means making progress that survives real users, real permissions, production load, container rebuilds, unreliable dependencies, and the operational mess that appears once an AI colleague is actually doing work.
The backlog is mostly hardening the substrate.
The recurring problems are systems problems: making new employee environments faster to create, making tool access reliable without disrupting live work, separating local learning from managed behavior, building privacy-preserving review artifacts, and proving memory, retrieval, and tool capabilities through layered checks instead of optimistic dashboards.
We also spend time turning one-off operational pain into shared infrastructure: better provisioning, safer upgrade paths, stronger isolation, fault-tolerant intake, reproducible QA for files and media, and clearer promotion paths for improvements learned by one employee to become available to many.
The bar is ownership, not ticket completion.
You should be able to own a surface end to end: understand how it works, improve it, measure whether it got better, and fix it when it breaks.
We value people who can move quickly without lowering the standard, and who know how to use agents to compress implementation time without compressing their own judgment.
Good judgment matters more than cleverness.
There are many ways to make an agent do something impressive once. There are fewer ways to make it useful every day inside a team that depends on it.
- You should notice when a workflow only works in a demo and not in a live customer account.
- You should care about the exact moment an AI colleague should ask for confirmation, retry, defer work, or stop.
- You should understand how memory can help an agent reason, and how it can quietly make the system worse when retrieval is wrong.
- You should be able to trace a failure from the user-visible symptom through state, routes, logs, generated files, environment setup, and dependency behavior.
- You should care about infrastructure that compounds: faster builds, better fixtures, safer syncs, and quality checks that catch regressions before users do.
- You should be able to explain a system to a founder, a user, and another engineer without changing the truth.
Who tends to thrive here.
People do well here when they are unusually comfortable with ambiguity, unusually allergic to fake progress, and unusually interested in the messy boundary between software, infrastructure, language, memory, and organizations.
If you like owning a problem end to end, if you already use AI systems as part of your own work, and if you want to help define what it means for intelligence to join a company as a colleague with its own tools and responsibilities, you will probably find the work energizing.