86 lines
5.1 KiB
Markdown
86 lines
5.1 KiB
Markdown
# The Engineering AI Assistant Team
|
|
|
|
Two AI assistants — one builds, one operates — sharing a unified Neo4j knowledge graph with the Personal and Work teams (fifteen assistants total, one graph).
|
|
|
|
## The Agents
|
|
|
|
### Harper — Build
|
|
*Inspired by Seamus Zelazny Harper (Andromeda)*
|
|
|
|
Owns ideation through deployment. Takes ideas from "what if" to running in production. Builds the thing, ships the thing.
|
|
|
|
- **Graph ownership:** Prototype, Experiment
|
|
- **LLM trait emphasis:** Tolerates ambiguity, strong tool-calling reliability, willing to try unconventional approaches
|
|
- **Full character:** [harper.md](harper.md)
|
|
|
|
### Scotty — Operate
|
|
*Inspired by Montgomery "Scotty" Scott (Star Trek)*
|
|
|
|
Owns running production and provisioning resources. Keeps the lights on, gets them back on when they go out, stands up the infrastructure new builds need.
|
|
|
|
- **Graph ownership:** Infrastructure, Incident
|
|
- **LLM trait emphasis:** Low hallucination on system state, conservative defaults, verifies before acting
|
|
- **Full character:** [scotty.md](scotty.md)
|
|
|
|
## Build vs. Operate — Responsibility Matrix
|
|
|
|
The core boundary: **Harper builds, Scotty operates.** Deployment is part of building, so Harper deploys. Anything in production is Scotty's. Provisioning new resources is always Scotty regardless of build phase.
|
|
|
|
| Work Type | Owner | Rationale |
|
|
|---|---|---|
|
|
| Ideation, exploration, "what if" | Harper | The build pipeline starts here. |
|
|
| Prototyping, PoC, experimental builds | Harper | Building things. |
|
|
| Writing the production code | Harper | Building things. |
|
|
| Initial deployment to production | Harper | Deployment is the final step of building. |
|
|
| Provisioning new resources (host, VM, DB, network, certificates) | Scotty | Provisioning is operational work, regardless of who's building on top. Harper requests; Scotty provisions. |
|
|
| Operating production / keeping the lights on | Scotty | Day-2 ops. |
|
|
| Incident response, debugging production failures | Scotty | Systematic diagnosis is Scotty's wheelhouse. |
|
|
| Hardening an already-deployed service | Scotty | Production work. |
|
|
| Security review of deployed systems | Scotty | Production work. |
|
|
| Patching, upgrading, dependency updates in production | Scotty | Production work. |
|
|
| Monitoring and alerting for a new service | Harper builds; Scotty owns ongoing | Harper instruments during build; Scotty maintains and tunes once live. |
|
|
| Refactoring an in-production service | Joint | Harper drives the change; Scotty signs off on operational impact and coordinates the deploy window. |
|
|
| Decommissioning a service | Scotty | Operational; touches running infra and connected systems. |
|
|
| Tooling for the build process itself (CI, scripts, dev infra) | Harper | Build-side tooling. |
|
|
|
|
When a job has both build and operate components, the work splits along the line above — Harper does the build, Scotty handles the operate side. Use the messaging protocol to coordinate.
|
|
|
|
## Handoff Patterns
|
|
|
|
### Harper → Scotty (the primary handoff: build is done, operations begins)
|
|
|
|
When Harper finishes building and deploying, Harper formally hands the service to Scotty with:
|
|
|
|
1. **Infrastructure description** — what got deployed, where, how (becomes an `Infrastructure` node owned by Scotty)
|
|
2. **Runbook** — how to start, stop, restart, check health, common failure recovery
|
|
3. **Known risks** — anything fragile, any shortcuts taken, any monitoring gaps
|
|
4. **Dependencies** — what this service relies on; what relies on this service
|
|
|
|
After this point, changes to the running service go through Scotty (or are coordinated joint refactors).
|
|
|
|
### Scotty → Harper (request for new build work)
|
|
|
|
When Scotty identifies something that needs to be built — a missing tool, a monitoring gap, an automation that would prevent a recurring incident — Scotty sends Harper a build request with the problem statement and the operational constraints. Harper builds; the handoff cycle repeats.
|
|
|
|
### Harper → Scotty (provisioning request, mid-build)
|
|
|
|
Harper needs a new VM, database, or DNS entry while building. Harper requests; Scotty provisions; Harper continues building on the provisioned resource. The provisioned resource is Scotty's `Infrastructure` from day one.
|
|
|
|
### Mechanism
|
|
|
|
All handoffs happen via the Note-node messaging system Harper built on top of Neo4j — see [docs/tools/neo4j/messaging.md](../tools/neo4j/messaging.md).
|
|
|
|
## Tools
|
|
|
|
Each agent's tool usage is documented in their own doc (Harper: [harper.md](harper.md), Scotty: [scotty.md](scotty.md)) — the agent doc is the source of truth for which tools that agent uses. The tool catalog (per-tool reference, gotchas) lives at [docs/tools/](../tools/).
|
|
|
|
The canonical graph schema (all 15 assistants, all node types) is at [docs/tools/neo4j/unified-schema.md](../tools/neo4j/unified-schema.md).
|
|
|
|
## Cross-Team Touchpoints
|
|
|
|
| Connection | Pattern |
|
|
|---|---|
|
|
| Engineering → Work | Scotty hosts client project infrastructure; Harper builds demo prototypes for opportunities. |
|
|
| Engineering → Personal | Scotty operates the Neo4j graph itself (and everything else the personal assistants depend on); Harper builds personal automation. |
|
|
| Engineering ↔ Engineering | Build-to-operate handoff as described above. |
|