The Harness Council: an operating philosophy for AI knowledge work

Four labels carry the whole report

This is a first-person experiment, written from the experimenter’s point of view. The strongest thing in it is a way of thinking. So every claim carries one of four labels, and the labels never blur.

Why label at all?

Raja’s setup has grown fast: roughly two months of solo work, five harnesses, a routing layer, a pile of skills and several tool servers. Fast growth produces a lot of “I think this works”. The council itself is built to separate that from “here is the log that shows it works”. This report applies the same habit to itself.

What this report is, and is not

A solo experiment with a system-level idea

Raja leaves a voice message. The message becomes tasks. The tasks get done, documented and archived. The interesting part is everything that has to be true for that sentence to hold.

The experiment in four moves

• Council before output. Deep research and council review happen before anything is produced, so the answer has been argued with once.REPORTED
• Skills are hired, not just installed. Skills come in from proven sources or are distilled from frontier models, then adapted, documented from Raja’s point of view and monitored.REPORTED
• Tokens are a budget. Compression tools cut usage. A routing layer spreads the rest over providers. A weekly report hunts for more free capacity.REPORTED
• Trust is earned by evidence. Evals and security skills watch the work loop. Tasks close on proof, not on an agent saying “done”.DESIGN

It is more like a software company acquiring team members with various skills.Raja, voice note, 14 Oct 2026

What the evidence says today

The breadth of the setup and the coherence of the operating model are well described. The efficiency and reliability claims are hypotheses to be measured. A hand-off from the cloud assistant Instinct to the council has been tried; its live validation on 13 October did not produce proof, and this report says so plainly in Part 9. That honesty is part of the method, not a footnote to it.

Laya, a decision-support engine, sits beside the harnesses as an advisory layer, not an execution harness. Its outputs are not yet verified.

Why a council, and why it is shaped this way

Every design choice in this setup comes from one habit: decide who is best placed to do a job, say so out loud, and check the result against evidence.

The right person for the right job. That is the analogy I picked up for how models get used.Raja, voice note, 14 Oct 2026

Raja did not set out to collect tools. He set out to stop being the integration layer between them. When the same person briefs the research tool, copies results into the coding tool, pastes errors back, and files the outcome by hand, the person is the bottleneck. The council moves that coordination work into a system that can be inspected and improved.

Three beliefs underneath

The experimenter’s stance

This is explicitly an experiment. Raja describes it as experimental, and he is also clear that “self-diagnosis” and “self-healing” are not jargon he picked up: he built them in and says he can demonstrate them on request. Both statements sit together here: curious about the edge, strict about what is shown.

Eight operating principles

The principles are short on purpose. Each one can be tested against any task the council runs.

How they interact

“Derive first, ask second” saves Raja’s attention. “Proof before done” protects it. “Cost is a design input” keeps the system affordable enough to run daily. “Safe by default” is what lets the other seven run with a degree of autonomy. Take any one out and the others get riskier.

How the experiment grew

Two months of solo work, reported by Raja, compressed into a few visible steps. Dates come from his own messages.

What changed along the way

• The harness list moved. Earlier descriptions mention a DeepSeek harness and two further council members; the 14 October description names Hermes, OpenClaw, Antigravity 2.0, Claude Code and OpenWorker.REPORTED
• Hermes went from “one useful agent” to “the orchestrator”, with a Kanban for task state.REPORTED
• A skill gate arrived once it became clear that skills can carry real risk (see Part 4).OBSERVED
• Brand and design standards were handed to the council as a standing rule in October.OBSERVED

The solo-builder lens

A solo builder can move quickly and make bold design choices, but also has no second pair of eyes. That is exactly why the council includes review and why evidence matters. The experiment is a proof of integration breadth and rapid learning. It is not yet proof of robustness at scale.

The whole system on one page

Requests flow in at the top, get turned into tasks by one orchestrator, are executed by specialist harnesses, and rest on a shared layer of tools and model routing.

Reading the map

• Top to bottom is accountability. The orchestrator owns the task. Everything beneath it executes or supports.
• Left and right of Hermes sit the two habits that protect output: research before, review during.
• The advisory strip at the bottom is Laya, a decision-support engine Raja installed to help with prioritisation. It advises. It does not execute work and it never grants approvals. Its role is as Raja reports it; its integration is under development and its outputs are not yet verified.
• The base layer is where cost is controlled. It is shared, so every harness benefits from the same routing and compression.

Seven layers, one principle each

A layered view helps decide where a problem lives. A wrong answer is usually a context problem (L1), a routing problem (L5) or a verification problem (L6), not a “the AI is bad” problem.

The principle: keep one accountable orchestrator

Multiple harnesses can execute. Only one owns task state and final closure. When two components both try to orchestrate, you get duplicated retries, conflicting state and “who owns this?” arguments. The council avoids false redundancy: more agents is not more reliable unless there are explicit contracts, artefact ownership, independent checks and bounded retries.

The council: who does what

Routing should follow capability, not brand preference. Task type, available tools, reliability, context need and risk decide who gets a job.

Examples of capability routing

• Code change: a code-capable harness, then tests, then a diff review by someone else.
• Browser inspection: a browser-capable agent with a scoped allowlist.
• Structured research: a research path with source capture, then council challenge.
• Independent verification: a harness that did not write the work.

Laya: an advisory decision layer

Laya sits beside the harnesses, not among them. The harnesses do work. Laya is meant to help decide which work comes first.

How it fits the council

• Laya advises. Its priority, classification and triage suggestions go to Hermes, which decides what to do with them.DESIGN
• Security and escalation calls from Laya are advisory only. The 13 Oct view showed a contract note saying they never grant or bypass approvals, and a separate deterministic authorisation layer outside Laya.OBSERVED
• The cost idea is to ask a cheap decision layer before spending a model call. That is a design intent. No saving is claimed.DESIGN

What would move this from reported to observed

• Raw process, configuration and output evidence from the installed copy.
• A passing test run, with its output attached.
• Ten ranked lists, Laya against an unaided ranking, judged by Raja.ROADMAP

Project description: github.com/NandhaKishorM/laya (see Reference sources).

Council before output

The council idea borrows from the “LLM council” pattern: put several strong perspectives on the same problem before one answer is written. Raja made it a rule, not a feature.

Why it matters

A single model asked for a report gives the report it would give to anyone. A council round forces a position, an opposing position and a list of what evidence would settle it. The result carries its own uncertainty, which is what a decision-maker needs.

What Raja reports

• Deep research and council-style work are enabled before any output is produced.REPORTED
• Work is “pitched between harnesses”, each with a designated job.REPORTED
• No measured quality difference exists yet. The measurement plan in Part 10 would test this directly.ROADMAP

From a voice note to a finished deliverable

This is the sentence Raja uses: leave a voice message, it becomes tasks, tasks get done. Here are the seven steps hiding inside it.

Human intervention policy

The target is minimal intervention, not unbounded autonomy. Approval is required for destructive operations, external publication, credential changes, production deployment, spending, sensitive data access and irreversible actions. Conflicting requirements or thin evidence also escalate to Raja.

Two control planes, one source of truth each

Raja separates “what is happening” from “what we know”. The Kanban tracks the first. Notion or Obsidian holds the second.

Task plane

The Kanban is the operational ledger: status, assignment, dependencies, blockers, review state. A card does not move to Done because an agent says so. It moves when acceptance evidence is attached.

Document plane

Whatever the council produces is archived where Raja can find it: research, decisions, test evidence, runbooks and lessons learned. Choosing one canonical location per artefact class, or defining sync rules, avoids two competing records.

Context engineering: turning a vague ask into a work order

A general model starts with no knowledge of the organisation, the role or the standards. Context is what makes a request bounded.

Derive first, ask second

• Inspect existing documents, repositories and prior decisions.
• Label each item: verified fact, inference, assumption, unknown.
• Ask Raja only for what would materially change the approach.
• Never silently invent an organisation-specific fact.

I provide decent context about what I am trying to accomplish, and it jots down the documentation and creates the artefacts.Raja, voice note, 14 Oct 2026

Skills are hired, not just installed

Raja’s analogy is a company hiring people with different skills. A good hire is vetted, onboarded, given documentation and reviewed. A skill gets the same.

Two ways skills arrive

Beyond ingestion

Once a skill is absorbed, Raja publishes documentation beyond what the vendor provides. It records what he needs to learn from it, how he intends to use it, and what makes it effective and efficient. That documentation is where a generic skill becomes his skill.REPORTED

What has been added so far

Raja’s three most recent additions, in his own words, plus other skills commissioned during intake.

The documentation habit

Every absorbed skill gets a short page: what it is for, how Raja intends to use it, a worked example, known limits, and how to turn it off. The page lives in the document plane and is linked from the skill’s task card.

From a GitHub URL to a decision

Raja finds a repository somewhere, say a post about something it can do. He does not want to decide by himself. He pastes the URL and wants the system to judge it against what he has set as his objectives.

What is reported, what is design

Raja reports a distillation skill in Hermes that evaluates a repository against the objectives he configured: cost efficiency, token efficiency, and getting knowledge work done at minimal or zero cost.REPORTED The step from “recommend” to “install and run” is a design choice: pasting a URL is a request to evaluate. It is not permission to execute unknown code.DESIGN

Repository gap assessment: how a verdict is reached

A gap assessment compares what a repository offers with what the council already has. The verdict is one of four words, with the reasoning attached.

Worked pattern: a skill collection under review

In early October Raja asked Hermes to learn a public collection of agent skills, but first to run a skill-inspection tool over each one, so that only good and secure skills were absorbed, then assign them to the profiles that need them. He said they need not be absorbed verbatim.OBSERVED

The first pass reported 173 skills “absorbed”. The check on 7 October found evidence that looked like a relabelled text search, not the real inspector (which had been expected to run hundreds of scans in seconds). It was sent back for proof and a shortlist of 20 to 40. This is the gap assessment doing its job on the assessor.OBSERVED

Illustrative verdict card

MCP, browser, computer and terminal: a ladder

Raja is adding multiple secure MCP servers to give the council tools to reach different systems. The question is which tool to use when.

What is reported

• Playwright MCP and a second testing MCP support frontend and backend test generation and execution; terminal access is also through MCP.REPORTED
• The second testing MCP is not named in the source; the inventory should record it.

The model-context-protocol standard lets a tool or data source be exposed to a harness in a uniform way. A connector being listed does not mean it is configured, authorised, secure or right for a given task.

Security: least privilege and approval gates

The council has real reach: a local filesystem, a terminal, scheduled tasks. So the security model has to be real too.

Priority risks

• Excess tool permission or broad filesystem and terminal access.
• Prompt injection through web pages, repositories, documents or MCP replies.
• Secrets leaking into logs, chat transcripts or artefacts.
• Unsafe skill intake and unreviewed dependencies.
• Runaway retries, duplicate tasks, resource contention.
• False completion claims with no test evidence.

The skill-intake gate, as it has actually run

Rules are easy to write. What counts is whether they bite. Here is what the intake gate caught.

Sources: assistant status messages to Raja on WhatsApp, 26 Sep 2026 (09:31) and 7 Oct 2026 (07:02); his instructions of 26 Sep and 7 Oct.

An older warning to re-check

An earlier readiness assessment of OpenClaw flagged an insecure authentication setting on its control interface. This is historical context, not a statement about today. Before the gateway is exposed beyond a trusted local boundary, the active configuration should be re-inspected and any insecure setting closed.ROADMAP

Compliance posture

Personal data is a category, not a standard. Payment-card rules apply inside their defined environment. Standards bodies have different scopes. The council does not claim compliance from a prompt; applicable controls are selected from the real jurisdiction, contract and system boundary.

Token economics: reduce, reuse, route

Tokens are the running cost of AI work. Raja treats them like a budget with three levers.

What Raja reports

• Tools such as Headroom and Ponytail are used to reduce token usage.REPORTED
• Even with those, some tokens still cost money from third-party providers. OmniRoute and FreeLLMAPI are in the setup to cover that.REPORTED
• Reported cloud and API credit spend over the two months is zero. This is his figure and has not been audited.REPORTED

The weekly provider hunt

Free and low-cost API capacity changes constantly. Raja turned the hunt into a routine so it does not depend on remembering to look.

Each week a report reviews the providers already configured, leaves them out, and looks for others offering API tokens. Raja then obtains and configures those in the OmniRoute dashboard. His role has shifted from “doing the work” to “signing up for more capacity”.

Controls worth adding

• Record provider terms and rate limits next to each key.
• Check that “free” really means free before a provider enters the route.
• Keep sensitive work off providers whose data terms are unknown.
• Store keys in a managed secret store, never in notes or chat.DESIGN

The right model for the right job

Raja has tightened how models are used. The routing table below is illustrative: it shows the shape of a policy, not his actual configuration.

A lesson from earlier troubleshooting

A model without native tool-call support, placed in a route that needed tool calls, led to raw JSON appearing in a chat channel. Model capability must be declared, not guessed. Other recorded themes were rate-limit fallbacks and authentication failures (HTTP 401 and 502). Each one is an argument for end-to-end integration tests on the route itself.OBSERVED

Resilience patterns

• One authoritative route per class of request.
• Bounded retries and failure-specific fallbacks.
• Health checks, timeouts, circuit breakers and named error categories.
• Tests for rate limits, auth failure, outage, malformed tool calls and recovery.

Self-diagnosis and self-healing, made concrete

Self-diagnosis and self-healing mean a system that notices its own failures and repairs them within limits. Raja reports that he has built both in and offers a demonstration. A recorded demonstration is still pending. Here is the loop.

What is documented, what still needs a demonstration

• Raja reports that self-diagnosis and self-healing are implemented. He offers a demonstration.REPORTED
• Raja asked on 25 Sep for a daily 7:00 AM run: stop harness processes safely, update, health-check, restart. It was specced with a pre-flight backup.OBSERVED
• A recorded demonstration (a failure injected, detected, repaired and re-tested) would convert this from reported to observed.ROADMAP

Evals and security layers around the work loop

Raja describes evaluation and security as layers wrapped around the loop, with several skills continuously watching the work as it is done.

Definition of done

Code generated is not code verified. A change is complete when required tests have actually run, evidence is captured, known failures are dispositioned and the deliverable meets its acceptance criteria. This is the point where the Kanban and the evals meet.

Failure modes the loop is meant to catch

What went wrong, and what it taught

A system worth trusting has a record of failing and getting better. These are real, redacted lessons from the setup so far. None of them is hidden, and none changes the design. Each one added a control.

Sources: dated assistant and user messages on WhatsApp, 25 Sep, 29 Sep and 7 Oct 2026, and the 13 Oct hand-off check.

Prioritisation rule

Raja’s guidance in September: stabilisation and improvement come first, deliverables take a back seat unless he overrides. Hardening is not a permanent activity; beyond a certain point, the tightening stops.OBSERVED

What the council is used for

Typical use cases, in Raja’s words: case studies, deep research reports, code and security audits, and enhancing existing codebases with new features. Others have grown around them.

Common shape

Whatever the request, the shape is the same: Raja gives context, the council plans, executes and verifies, the output lands in the document plane with its evidence, and the card on the board closes. Only the domain context and the acceptance criteria change.

Industry-agnostic, with limits

The execution framework is separated from the domain context, so the same approach can apply to product management, engineering, research, business analysis, operations and audit. Portability is limited by tool schemas, authentication, model capability, licences and provider behaviours.

Use case 1: deep research reports

The council earns its keep when the question is open and the answer must be sourced.

Standards

• Prefer primary sources, standards bodies, vendor documentation and peer-reviewed evidence.
• Separate fact, interpretation, estimate and recommendation.
• Capture URLs, dates, evidence quality and contradictions.
• Report limitations in the document, not in a side message.

Deliverable shape

Use case 2: case studies

A case study documents a problem, its context and what was done about it.

The measured-or-illustrative rule

Where measured results exist, the case study reports them. Where they do not, it is labelled a design case or illustrative scenario and makes no claim of observed impact. This one rule keeps the case-study library credible.

Reuse

Each completed case study leaves behind reusable parts: decision records, prompts, test fixtures and runbooks. Before repeating research, the council searches those, then revalidates anything time-sensitive.

Use case 3: code and security audits

Point the council at a codebase and get findings, not vibes.

Engineering contract

• Inspect the existing architecture before changing it.
• Plan with acceptance criteria before implementation.
• Make small, reviewable changes that preserve existing behaviour.
• Run formatters, linters, unit, integration and UI tests.
• Use Playwright or an equivalent for browser-level checks.
• Review diffs for security, regressions, secrets and unintended scope.
• Record test commands, results, known gaps and rollback steps.

Use case 4: from idea to shipped code

Raja’s personal website is the working example of turning rudimentary thoughts into code.

What is observed

• The personal website was restyled on the Signal brand kit and put live within a day of the brand decision.OBSERVED
• Frequently asked questions and brand pages on the site were refined using the council workflow.REPORTED
• The “enhance an existing codebase with new features” use case is on the pipeline, with audits first.REPORTED

What a good change looks like

Use case 5: policy, brand and knowledge deliverables

Not all knowledge work is code or research. Policies, guides, checklists and brand assets matter too.

The brand rule as a worked example

On 11 October Raja chose the Signal direction and said every future deliverable should use the new brand kit, including those made by Hermes. The proof bar he set for Hermes was concrete: the rule stored persistently, one sample deliverable on the kit, and a negative test that flags a deliverable that does not follow it.OBSERVED

Repeatable production jobs

For recurring deliverables such as checklist series, the cloud assistant packages a spec, a worked example, a skill and a test task. Hermes builds. The result is verified before anything is posted. Raja’s instruction was to train Hermes to do it, not to keep doing it for him.OBSERVED

Use case 6: reverse engineering and learning new tools

One of the newest skills lets the council study a software utility and explain how it works.

Why it matters for a solo builder

New tools appear weekly. Instead of reading every vendor manual, Raja can ask the council to learn the tool, then write the documentation he would want: what he needs to know, how he intends to use it, how to make it effective and efficient.REPORTED

Guardrails

• Only analyse software he is entitled to analyse.
• Work in isolation. No credentials in scope.
• Record findings as notes and hypotheses until tested.
• Respect licence terms in anything republished.

Two assistants, one liaison rule

Instinct is a cloud agent platform Raja talks to. Hermes is his local orchestrator. His instruction was to make them shake hands and work together.

I want Hermes to do the heavy lifting while you serve as my liaison.Raja, 25 Sep 2026 (paraphrase of voice note)

What is proven, what is still being validated

The hand-off between the two assistants is a design intent and a work in progress. It should not be presented as a proven integration.

What the lesson is

A message that was delivered is not a task that was picked up. The right test of the hand-off is an end-to-end one: a small task goes in, a proof comes out, and the proof is checked by someone other than the doer. Until that has passed a few times, the integration is a promising design, not a dependency.

Rules that already govern the hand-off

• One work item at a time when remediating, closed on raw proof before the next starts.
• Open questions for Raja become an explicit checklist for him, not text buried in comments.
• Anything that could damage, widen blast radius or touch protected systems waits for him.

What this is worth, without inventing numbers

No ROI figure appears in this report because none has been measured. The value below is stated as mechanism: what problem it removes, how, and what proof would show it.

Where the approach applies

The operating model is built around one person, but its parts travel. What changes as the audience grows is governance, not the core idea.

Concrete value for Raja’s own work

• Case studies and research reports produced from a voice request, with sources.
• Security and code audits that hand back findings and a fix plan.
• Brand-correct documents, pages and images by default.
• A growing library of documented skills in his own terms.
• Showcase material: this report, the architecture and the lessons.

What it is not claiming

No claim of savings in hours, rupees or tokens. No claim that a team could adopt it as is. No claim that the council beats any particular commercial product. Those are the questions the measurement plan answers.

Evidence ledger

One table that says what stands behind each claim. If a claim is not here, it is not made.

The measurement plan: make the claims testable

Pick ten to twenty representative tasks across research, case-study writing, coding, browser workflows and testing. Run each under a baseline workflow and under the tuned council, with the same criteria.

Controls

• Same tasks and model settings where possible; a written review rubric.
• Record hardware, model versions, cache state and network conditions.
• Report sample size and variability.
• Do not credit one tuning change when several changed at once.
• For Laya: compare its ranking with an unaided ranking on the same inputs and have Raja judge which he would have acted on. One or two lists prove nothing; ten or more start to.

Raja’s stated route to quantification is also the right one: collect token use, provider, time, retries, cache hits and completion across baseline and tuned runs. A handful of measured results will do more for credibility than a longer feature list.

From experiment to a reproducible system

Five phases. Each one ends with something that can be inspected.

Exit test for each phase

Open items still to confirm

These are the facts that need Raja’s confirmation or a quick check. None blocks the report. All of them affect how confidently it can be shown externally.

Reproducibility pack and glossary

If someone else were to repeat the experiment, they would need this list.

Glossary

Reference sources

Nine pages were fetched on 14 October 2026 and loaded. One further page from the source dossier (the Hermes MCP integration page on GitHub) returned a server error and is left out. Re-check each page when it is updated.

Source of the user’s own statements

First-person description: Raja’s voice notes of 14 October 2026 (about 06:17 to 06:34 IST) and his written messages. Earlier context: his messages from 24 September to 11 October 2026 on the council, delegation rules and brand kit. Products and tool names are used as Raja named them; no vendor claim is independently verified here.

Design: RJ Signal v1.0.0 brand guidelines and public assets (rajajeevan.com/brand), read 14 October 2026. Diagrams were drawn for this report and show Raja’s external architecture only.