01 / How we approach the work
Engineering Doctrine
Agent first. Help early. Never wait alone.
At E3, independence means owning the fastest path to a verified outcome—not doing everything alone. Reach enough confidence to make the next decision, then keep learning.
Build only enough to learn what comes next.
Find the decision holding us back. Run the smallest test that can change it, using what already exists. Let evidence guide the tech tree. Do not build infrastructure for an experiment you can already run.
Don’t multiply an untested assumption. Improve the signal-to-noise ratio: add evidence, not noise.
From our work: Shield needed detection for seven image types. Testing one in production—with monitoring and rollback—could tell us whether the approach worked before building the other six. Learn first so we don’t repeat the same mistake six more times.
Start with an agent. Ask for help early.
Give an agent the goal, success criteria, context, and uncertainty. Then ask people who can help—do not wait for the agent to finish or struggle alone. Agent availability must never delay urgent help.
You still own the decision and verified result. Use every available resource to reach useful confidence quickly.
From our work: A Shield engineer asked a teammate for missing context while an agent investigated in parallel. Asking for help did not mean stopping the investigation and waiting for a reply.
Do not wait without learning.
Ask for help as soon as you are blocked. Fifteen minutes without new evidence is a backstop—not a waiting period.
While a task runs, give other agents independent questions and combine their findings. Parallelize learning, not duplicate work. A long-running experiment is not a reason to invent busywork.
From our work: Docs tested its bug-fixing skill on five distinct failures, including OCR, charges, and document classification. That is useful work to split: separate cases, isolated tests, shared review.
Respond quickly so other people can keep moving.
Respond quickly. If you cannot answer yet, acknowledge the request, share its state, and say when you will follow up.
The team owns routing blockers to someone who can resolve them. The original owner stays engaged until the work is unblocked—not just acknowledged.
From our work: Frontline’s Cloudflare access request was acknowledged within seconds; a change and retry request followed in under two minutes. Resolution still requires confirming the retry works.
Certainty of uptime.
You build it, you own its stability and the analytics others use to judge it. Measure whether critical workflows work. Know how they can fail; review monitoring and error tracking, and test that alerts reach a responsible person before—or as—users are affected.
Failures happen. An outage without timely detection is a severe failure of ownership. Fix the detection gap as well as the outage. That is how we keep people’s trust.
From our work: Shield’s database-backed requests timed out while an application-only health check stayed green. The check proved the process was alive, not that the workflow worked.
Verify the outcome.
Investigations must advance knowledge; delivery must pass the agreed checks in the relevant environment. Test the user outcome, not just edited code. Agent agreement alone is not verification.
Distinguish implemented, merged, deployed, and verified. Record what remains uncertain, and turn lessons into reusable tests, tools, or defaults.
From our work: In a Frontline staging call, the agent understood the load number correctly, but a later check blocked the lookup. A correct model answer wasn’t a working product: verification had to follow the request through to finding the load.
The expectation is simple.
- Define the outcome.
- Run the smallest useful experiment.
- Start agents and ask people early.
- Parallelize independent work.
- Share evidence and unblock each other quickly.
- Know first when our tools fail; verify the result.
- Make the next iteration easier.
What did this teach us about how we work?