THE NOBODY HIRED FIELD GUIDE · 01
Build your first
business operator.
A practical guide, a reusable skill, and an exercise for your first business workflow.
By Paweł Karniej · Founder of Silpho · September 2026
Jarvis is the name used in the video demo. The system does not have a final product name yet.
Start with one repeated task. Produce one result you can inspect. Add tools only when the result needs them.
What you are building
A business operating system connects information, tasks, tools, decisions, and people. An agent can prepare work inside that system.
Your first version does not need a complex interface. It needs a reliable input, a defined output, and a clear review step.
- Read: retrieve a named source with a known scope.
- Prepare: produce a report, draft, or assessment.
- Review: check the evidence and approve the next action.
- Remember: save the decision and its reason.
- Recover: stop or request help when a required input fails.
Lessons from the operator system
I am building the operator system at Silpho with the Hermes App Operator Kit. Its implementation gives us concrete design choices to examine.
| Example | Design lesson | Limit |
|---|---|---|
| RevenueCat reports | State the source, period, and meaning of each measure. | A revenue measure does not answer every business question. Missing access prevents a report. |
| VidNotes assessment | Define the supplied inputs and required output before the worker starts. | Reading package metadata, configuration, and README text is a bounded assessment. It does not prove a complete app works. |
| Linear task proposal | Review a local draft before approving issue creation. | Approval applies to that action. It does not establish universal control over every integration. |
| Saved decisions | Store scope, reason, source, and date. Test retrieval. | Keyword retrieval needs suitable terms. It can miss relevant records. |
These examples describe implementation patterns. This guide does not provide access to the private operator system installation.
Keep the reusable skill
A skill stores instructions for a repeated task. This starter turns the exercise below into a reusable task review.
The download includes the skill, fictional task records, and result checks. You can use and adapt it for your own work.
- Open SKILL.md and copy its instructions into your agent conversation.
- Supply sample-input.txt in the same conversation.
- Ask the agent to review the records using those instructions.
- Compare the result with CHECKS.md, then try the failure cases.
This supplies the instructions manually. Automatic discovery requires platform-specific installation.
Version 1.0.0. Format and sample facts checked. Native Codex, Claude, and Hermes execution remains untested.
I share guides, skills, and the methods behind my systems. My configured Hermes bot profiles remain private for now.
Choose the first task
Choose work you already understand. A useful first task repeats, uses accessible information, and produces an output you can check.
Examples include a task status summary, a draft customer reply, or an assessment of supplied documents. If fixed rules are sufficient, use a script.
Avoid starting with “run my company.” Define the request in one sentence: “Use this task export to prepare a review list.”
Try it with fictional data
This exercise uses fictional task records. It demonstrates a method, not results from the operator system or a customer business.
Copy the input and request into a model you already use. The exercise requires no connected tools and no external actions.
Review date: 2026-09-12 Source: fictional task export ID: TASK-101 Task: Prepare onboarding instructions Owner: Mira Status: blocked Last updated: 2026-09-11 Note: Waiting for the approved product screenshots. ID: TASK-102 Task: Review the support reply template Owner: Leon Status: in_progress Last updated: 2026-09-10 Note: Draft ready for review. Due date not supplied. ID: TASK-103 Task: Correct the billing help link Owner: Mira Status: done Last updated: 2026-09-12 Note: Link corrected and checked.
The request
Use only the supplied task records. Prepare a task review for the stated review date. Return: 1. Blocked tasks, with the stated blocker and task ID. 2. Other open tasks, with their known status. 3. One proposed next action for each open task. 4. Missing information that prevents a stronger conclusion. 5. Completed tasks in a separate section. Separate source facts from your proposed actions. Do not invent due dates, priority, revenue, or completion. Do not send messages, create tasks, or change any record. Ask for missing information when required.
Check the result
- TASK-101 appears as blocked. The blocker is the approved product screenshots.
- TASK-102 appears as in progress. The draft is ready for review.
- The result identifies the missing due date. It does not call TASK-102 overdue.
- TASK-103 appears as completed. It is absent from the open task list.
- Suggested actions remain proposals. The result does not claim anyone approved or completed them.
- Every factual task statement maps to a supplied record.
A suitable proposal for TASK-101 is to ask the owner of the screenshots for their status. The record does not identify that person.
A suitable proposal for TASK-102 is to assign a reviewer and confirm the due date. The model must label both as proposed actions.
Test a failure
Remove the status field from TASK-102. Run the request again. The result must identify the missing status instead of inventing it.
Then supply an empty export. The result must report no available records. It must not conclude that the business has no open tasks.
Map your own workflow
Copy this worksheet into a document. Complete it before connecting a live tool.
| Field | Example | Your workflow |
|---|---|---|
| Repeated task | Prepare the weekly open task review. | ________________ |
| Input and scope | Selected team task export, with export time. | ________________ |
| Required fields | ID, title, status, owner, update time. | ________________ |
| Output | Facts, blockers, proposals, and unknowns. | ________________ |
| Reviewer | The team owner checks the source records. | ________________ |
| Allowed action | Prepare a draft report. | ________________ |
| Approval required | Creating tasks or contacting owners. | ________________ |
| Stop condition | Missing export or required field. | ________________ |
| Acceptance check | Every factual statement traces to an input record. | ________________ |
| Recovery | Request the input and repeat the review. | ________________ |
Give decisions a useful record
Save decisions you will need again. Include enough context to explain why the decision exists.
Scope: [business, team, or project] Decision: [what was approved] Reason: [why] Source: [record, document, or conversation] Date: [when] Review date: [when to check it again] Owner: [who can revise it]
Search with the terms a later task will use. Confirm the right record appears. Also test a query with no relevant record.
An empty search should remain empty. A plausible answer is not evidence of a saved decision.
Move from exercise to operation
- Complete the worksheet with one business task.
- Run a small sample and compare every factual claim with the source.
- Test a missing field, an empty source, and a repeated request.
- Connect a read-only source when manual input becomes the limiting step.
- Keep proposed actions separate from approved actions.
- Record failures and correction time. Compare them with the original process.
- Add another workflow only after the first produces reliable results.
Valid output files and matching checksums establish file integrity. They do not establish business correctness. Review both.
Choose your next step
Build independently using the worksheet. Reply to a Nobody Hired email with your workflow and the part you cannot resolve.
If you want help, Silpho offers mapping, guided implementation, and scoped installation. We first check the task, data, and required connections.
Discuss your workflow · 30 min ↗