Your way of working
The sequence your team follows, the people it hands work to, and the tools it uses.
A versioned role playbook
UH / 01 / Inside the employee
Intelligence is general.
Your company isn’t.
You hire someone for their ability. Then you teach them your business: what matters, how decisions are made and what good work looks like. An AI colleague needs that introduction, too.
Read the technical noteTechnical design / 09 September 2026
This note describes the target UnseenHire architecture and its evaluation criteria. Device provisioning, provider settings and any weight fine-tuning are established for each engagement; the diagrams are design specifications.
01 / Company onboarding
Capability gets hired.
Context makes it useful.
A new human colleague brings experience, but does not arrive knowing your latest priorities, internal vocabulary or unwritten standards. We make those expectations explicit for the AI role.
Your priorities
What comes first when speed, cost, completeness and quality compete. What must always stop the work.
A priority order and escalation rules
Your references
Approved documents, brand assets, repository conventions and examples of accepted work.
An authorised, dated source set
Your definition of good
The expected format, evidence, level of detail and reasons a reviewer would reject a result.
Acceptance criteria and review examples
Your authority structure
What the employee may read, prepare or change, and which actions require someone’s approval.
A permission and approval map
The onboarding principle
The model supplies general ability. Your company supplies the working context. The employee’s environment connects the two to a recurring responsibility.
The request
Prepare the project quantities.
An architecture practice where traceability matters more than a filled spreadsheet.
- Source of truth
- Use the approved drawing issue. Keep superseded sheets out of the working reference.
- Priority
- Surface contradictory dimensions before completing the quantity schedule.
- Standard
- Every populated line needs a location, unit, measurement basis and source.
The expected hand-over
- A working schedule in the practice’s template
- Open quantities kept separate from measured quantities
- Conflicting dimensions routed to the project lead
“Finish the quantities” becomes a defined, reviewable responsibility. A complete-looking sheet is no longer the only signal of success.
Illustrative company policies and expected outputs. These examples explain configuration; they are not live generations or measured results.
02 / Where the difference comes from
The same model.
A different working system.
The potential advantage is better fit to the job: less repeated briefing, more consistent hand-overs and actions governed by your rules. It must be demonstrated on your work.
| Dimension | Standalone model call | Configured employee system |
|---|---|---|
| Working context | The instructions and material provided to the model call. | A versioned company profile plus the current, authorised task context. |
| Priorities | Preferences must be supplied or recovered by the surrounding application. | An explicit order of priorities, with rules for conflicting objectives. |
| Continuity | Persistent memory requires an application around the model. | Task state and approved working knowledge belong to the employee’s private environment. |
| Action | Tool use requires an integration and an execution system. | Scoped API connectors, checked permissions and human approval at agreed decision points. |
| Quality | A plausible answer still needs task-specific verification. | The deliverable is evaluated against the company’s acceptance criteria and review effort. |
A well-configured AI platform can implement these same mechanisms. The distinction is the company-specific system, its operation and its evaluated results; the underlying model does not become universally more intelligent.
A system decomposition / Not a performance formula
Employee = model capability + company context + private state + permitted actions + verification
Changing the foundation model should not erase the role’s instructions or records. The proposed design stores those separately, versions the model configuration and requires regression checks before an upgrade.
03 / The unit of deployment
One employee.
One physical device.
The target deployment assigns a dedicated physical computer to each AI employee, with its own execution environment, private working state and separately authorised connectors. A pool of remote or local models provides the required capabilities.
1 employee=1 physical device+API connectors+approved models
Employee A
Physical device A
Private working data
Files · task state · retrieval index · approved memory
Dedicated identity & secrets
Employee credentials · access rules · encryption keys
Execution environment
Workflow runner · validation · local model, where selected
Employee A’s controlled API gateway
Only authorised requests
Approved connectors
Company systems with individually scoped permissions
Approved model APIs
Remote inference receives the content included in each request
Employee B
Physical device B
Private working data
Files · task state · retrieval index · approved memory
Dedicated identity & secrets
Employee credentials · access rules · encryption keys
Execution environment
Workflow runner · validation · local model, where selected
Employee B’s controlled API gateway
Only authorised requests
Approved connectors
Company systems with individually scoped permissions
Approved model APIs
Remote inference receives the content included in each request
No automatic sharing between employees. No shared working memory, private retrieval index, credentials or private training data.
Execution
A dedicated working environment.
The device hosts the role’s workflow runner and private state. Capacity is sized for the workload. Large-model inference may run elsewhere; the device is not assumed to contain every model’s weights.
Integration
Access with a defined purpose.
Each connector has an employee identity, an allowed resource scope and permitted operations. Reading a repository, preparing a draft and publishing a change are separate permissions.
Inference
Models selected for the task.
Document reading, visual interpretation and code generation may use different models. Routing must respect the company’s data policy before comparing quality, latency or cost. A blocked provider cannot be used as a silent fallback.
Physical ownership alone does not establish trust. Identity, authorisation and resource-level controls still apply. NIST · Zero Trust Architecture, SP 800-207
04 / Isolation is a system property
Separate employees.
Separate working data.
The design rule is no automatic transfer of one employee’s private files, memory, prompts, credentials or learning records into another employee’s environment—even inside the same company.
Required access invariant
Employee A cannot read Employee B’s private state.
Enforced by identities, storage boundaries and access checks. Never by a prompt alone.Private state
Separate files, indexes, task histories and memory stores. Retrieval must check access before selecting passages; filtering after generation is too late.
Credentials & actions
Per-employee secrets, least-privilege tokens and explicit approval for consequential writes. Document text cannot grant a permission or create a new connector.
Logs, caches & backups
The same separation extends to traces, prompt caches, snapshots and support access. Backup keys, retention and deletion procedures belong in the deployment specification.
Learning artifacts
Private examples and employee-derived fine-tuning artifacts must not be pooled into another employee’s training data or adaptation. Feedback is reviewed before it becomes retained knowledge.
A company may separately authorise the same brand guide or procedure for two roles. That is access to an approved company reference, not access to the other employee’s memory. Reusing the same public foundation-model weights also does not, by itself, share employee context.
The external service boundary
A dedicated device is not an air gap.
When a remote model API is used, the selected prompt, attachments and tool results sent in that request leave the device and are processed by that provider. The design requires an approved endpoint, limited payloads and reviewed retention, training-use and regional settings.
The target policy excludes employee content from shared model training. Local-only inference requires compatible models and sufficient hardware, with external inference disabled. API connectors still exchange data with the systems they connect to. The actual route must be documented for each role.
Provider training use and retention are separate questions. For example, OpenAI documents both API training-use defaults and endpoint-specific storage controls; those settings cannot be inferred from dedicated hardware. OpenAI · API data controls
Retrieved files and tool responses are untrusted inputs: embedded instructions must not be allowed to expand the employee’s authority. This addresses the indirect prompt-injection risk described by OWASP. OWASP · Prompt Injection
05 / What company adaptation actually changes
Teach the company.
Choose the right mechanism.
We use company adaptation as the broad term. Weight fine-tuning is one specific technique within it. A new instruction, a retrieved document and a gradient update are different operations.
Layer 01 / Instructions & policy
How the role should work.
A versioned playbook defines priorities, terminology, output formats and escalation rules. Updating the playbook changes the context supplied to the model; it does not retrain its weights. Hard access restrictions are enforced by the execution system.
Changes the working instructionsLayer 02 / Retrieval
What the role should consult.
Retrieval-augmented generation, or RAG, selects relevant passages from an authorised reference set and supplies them during inference. This supports current, attributable context without encoding every new document into model weights. Retrieval quality and source freshness still need checking.
Changes the evidence in the contextLewis et al. · Retrieval-Augmented Generation (2020)Layer 03 / Working memory
What the role should retain.
Approved decisions, task status and recurring preferences can be stored outside the model with their source, owner and review date. Corrections become proposed updates. Superseded entries are replaced or retired; a conversation is not automatically permanent knowledge.
Changes the employee’s private recordsLayer 04 / Weight adaptation
How the model behaves on a defined task.
Supervised fine-tuning updates model parameters using curated examples. A parameter-efficient method such as LoRA trains a smaller low-rank update while keeping the base weights fixed. This is a candidate for stable, repeated behaviours, subject to a held-out evaluation.
Changes weights or an adaptation moduleHu et al. · LoRA (2021)Technical detail / Low-rank adaptation
A precise meaning
for “fine-tuned”.
W′ = W + BA
In a simplified LoRA layer, W is the fixed base-weight matrix; B and A form a trainable update of rank at most r. If W has d × k entries, the update trains r(d + k) parameters instead of dk, with r chosen much smaller than d and k. A scaling factor is omitted here for clarity.
A company’s current project facts usually belong in a maintained reference system. Weight adaptation is considered when repeated evaluation failures suggest that curated training examples may improve a stable task pattern. It is not a substitute for permissions, source checking or review.
Hu et al. · LoRA (2021)The feedback cycle
Review → classify the correction → update the right layer → evaluate → approve the version.
A wrong source calls for a source correction. A changed priority calls for a policy update. A recurring behavioural failure may justify a training experiment. Every correction does not require retraining.06 / What would count as better?
A company-specific claim.
A company-specific test.
More configuration can add cost, latency and failure modes. The question is whether it improves accepted work in your environment, under the same practical constraints.
Define success first
Use representative tasks with a written review rubric: correctness, source traceability, format, prohibited actions and the human work needed to finish. Include missing information and contradictory inputs.
Compare useful baselines
Compare the same base-model version with a reasonable prompt, then add the company profile, retrieval and workflow in stages. Compare fine-tuning against the strongest non-fine-tuned configuration to isolate its contribution.
Keep the test independent
Separate configuration and training examples from held-out tasks. Split related documents by project where needed to reduce leakage. Repeat stochastic runs, record settings and blind the reviewers to the configuration when practical.
Measure the full hand-over
Report acceptance rate, defects, source support, human correction time, end-to-end latency and cost per accepted task. Report sample sizes and uncertainty; the model’s self-reported confidence is not a quality score.
Test the boundaries
Attempt cross-employee reads, revoked access, malicious document instructions and unauthorised writes. Check actual storage, connector, log and backup behaviour. Passing a finite test suite is evidence, not proof of zero leakage.
Release with evidence
Agree thresholds before the pilot. Version the model, playbook, reference index and connectors. Re-run relevant checks after a change and retain a working rollback path.
Two operational measures
Acceptance rate = accepted held-out tasks / all held-out tasks
Cost per accepted task = total evaluation cost / accepted tasks
Count failed attempts in the cost and define acceptance before reviewing outputs. Include human review and infrastructure allocation when estimating operational cost. If no tasks are accepted, the second ratio has no finite value.
This proposed pilot protocol takes a multi-metric view of quality. HELM provides a research precedent for evaluating models across scenarios and metrics instead of reducing performance to one headline number. Liang et al. · Holistic Evaluation of Language Models
Evidence available today
The first assignment is a worked example.
The architecture study contains inspectable quantities, a working model, a programme and coordination questions. It is not a controlled comparison against a standalone model, a fine-tuning benchmark or an audit of the device architecture. No numerical improvement is claimed here.
Inspect the first assignmentThe reason to make an introduction
Teach it how your company works.
Judge it by the work it returns.
The intended advantage is continuity: your priorities remain explicit, your sources remain identifiable and each assignment returns through a review process your team understands.
Private access / By introduction
Your way of working.
The first thing we learn.
Bring a recurring responsibility, an example of work you trust and the priorities your next colleague should understand.
Request an introduction