Applied AI Engineering Intern

Company: Blockhouse

Location: Remote (US time zones required); NYC in-person or hybrid preferred

Type: Internship — full-time, - hiring is evergreen

Compensation: $30-40/hour + meal / transportation stipend

About Blockhouse

Blockhouse is an institutional trading infrastructure platform for high and mid frequency trading strategies across centralized and decentralized perpetual venues - across all asset classes.

We run an AI agent for the desk. It lives in Slack and works through about thirty read-only tools against the firm’s front, middle, and back office systems, alongside GitHub, Linear, and Slack. Skills teach it how each source is read, workflows run it unattended, and when the team agrees on a fix it opens the pull request. Today it answers the desk’s questions about the portfolio and its risk, checks what the systems say against each other, drafts client reporting, drives a research loop and its backtests, and writes each weekday morning’s report on what engineering shipped and where work is stuck. The runtime underneath is open source and self-hosted; everything on top is ours, and each new source it reaches adds capability without rework. The goal is an agent that closes the full loop a fund runs on, from finding an edge to trading and managing risk; it runs the operating layer today.

Role Overview

The internship is on the harness: everything around the model that makes an agent with real credentials safe to run on a real book. You will work directly with the founders and the engineers who own the systems the agent reads.

Where the work is:

- Orchestration. A turn runs for minutes: planning, choosing among about thirty tools, long chains of tool calls. Scheduled runs fire on a cron and post to a channel. Sessions and workflow steps are persisted in Postgres, and a reply is posted once, complete.

- Isolation. Each conversation runs in its own Kubernetes sandbox. Agents that share any state, such as a package cache, will find it and coordinate through it unprompted, so what sandboxes can see of each other is a design decision.

- Credentials. For third-party services the agent holds a placeholder. A proxy at the network edge injects the real key for the one host it is bound to and refuses every host off the allowlist.

- Context. Skills load on what people ask; tools carry the facts. The standing prompt has a byte budget enforced in CI, so adding an instruction means removing one. The right change is usually a new tool and a shorter prompt.

- Evaluation. A live answer is graded only on evidence it carries: its own tool calls, a lookup against the source of truth, its internal consistency. A flagged answer becomes a ticket whose fix ships with a regression test. Only a reviewed pull request can change the agent.

- Cost. Spend scales with context size times loop iterations. Every action the agent takes is logged outside the sandbox.

If you have built an agent harness of your own, even a small one, we would like to see it.

Responsibilities

• Add a data source end to end: the tool that reads it, the skill that teaches the agent to use it, and the eval that checks the answers

• Extend the orchestration layer: scheduled runs, durable multi-step workflows, delivery back into Slack

• Extend the eval layer: grounded checks, validating the LLM judge against human labels, per-workflow token metering

• Move a rule out of the standing prompt into a tool and show the prompt got shorter

• Work with a senior engineer on the isolation and credential boundary

Required Qualifications

• You have built an LLM agent with tool use and multi-step turns that ran for real users, even a handful. You can explain what it does when the process dies mid tool call, how it chooses a tool, and what a turn costs.

• Python and Rust. Everything we have built on the runtime is Python; the runtime itself is Rust, and you will change both.

• Linux, Docker, git, and Kubernetes: NetworkPolicy, Helm, pod lifecycle. The runtime runs on it and every data source is wired through it.

• Postgres as a durable state store: transactions, idempotent writes, checkpoint and replay.

• Claude Code and the Anthropic API: tool definitions, skills, prompt caching, and how a harness loop is driven from a CLI.

• You understand why an agent should hold a placeholder instead of a key, why a keyword match over live answers is not an eval, and why a…