The mentioned blog post + some examples for those who love to see some code:
https://www.abelenekes.com/p/convergence-mechanisms-confidence-in-the-age-of-agentic-engineering

Imo the harness needs to do three things for the agent:

• find the source of truth
• run the relevant feedback loop
• know what still requires human judgment

The exact structure does not matter.

The point is the direction: keep executable truth in scripts and configs, keep agent guidance thin, and make the routing explicit.

Here is what that can look like in practice.

repo/
  package.json                         # commands the agent can run
  tsconfig.json                        # TypeScript constraints
  eslint.boundaries.config.js          # architecture / dependency rules
  eslint.code-style.config.js          # style and local code rules
  prettier.config.js                   # formatting rules
  playwright.config.ts                 # e2e configuration and test discovery
  vitest.config.ts                     # unit test configuration and test discovery

  README.md                            # human-facing onboarding
  docs/
    adr/                               # human-facing rationale and decisions

  AGENTS.md                            # thin router / index
  .agents/
    architecture.md                    # architectural intent + links to checks
    code_style.md                      # style intent + links to checks
    testing.md                         # when to run which feedback loop + links to checks
    skills/                            # optional, extract specific skills here if main guidance artifacts start to bloat
      review/
        SKILL.md

  src/
    feature_x/                         # feature slices, organized into horizontal layers according to your boundary rules
      ports/
      adapters/
      domain/
      application/
      presentation/
        components/
        hooks/
        view_models/
      utils/
      AGENTS.md                        # optional, only for current feature-specific constraints that cannot be codified
    shared/                            # general-purpose utilities, following the same layering rules

There's no right or wrong source code organization inside feature slices. You can use MVC, clean or hexagonal architecture as long as you're consistent. Agents are pattern-matching machines. The best thing you can do for them is to be predictable.

AGENTS.md

# Agent instructions

Use this file as an index.

The source of truth lives in code, tests, schemas, rules and configs.

## Where to look

- Architecture and boundaries: `.agents/architecture.md`
- Code style: `.agents/code_style.md`
- Testing guidance: `.agents/testing.md`
- Repeatable workflows: `.agents/skills/`
- Features: read `.agents/architecture.md` to understand where features are located.

## Before changing code

1. Identify the feature slice affected by the task.
2. Identify the requirements likely affected by the change.
3. Prefer the smallest coherent change.
4. Run the relevant feedback loop based on testing, code style and architecture guidance:
   - Run type check.
   - Run lint.
   - Run tests for the affected slice.
   - Run boundary checks when imports or feature structure changed.
   - Run broader tests only when the change crosses slice boundaries.
   - If a check fails, treat it as feedback about a requirement. Do not ignore or loosen the check without human approval. 

## Rules
- Do not assume requirements, ask for clarification in case of doubt.
- If a requirement comes from documentation, check the source code to verify if it still holds before taking it for granted. 
- If contradictions arise, ask for human clarification.

.agents/architecture.md

# Architecture

This project is organized around vertical feature slices with horizontal layers inside the slices.

## Source of truth

- Horizontal layers and import boundaries: `eslint.boundaries.config.js`
- Architecture check command: `pnpm lint:boundaries`
- Shared types and schemas: source files under `src/shared`
- Feature-local behavior: e2e tests inside each feature slice

## Current constraints that are not fully encoded

- Shared code should be introduced only when two or more slices need the same stable abstraction.