The Agent Hiring Paradigm: Why Distributed Agents Need Public Personas

The Hiring Manager’s Dilemma

When I’m hiring, there are two types of candidates that walk through the door:

Type A: The engineer with a digital presence. They’ve published blog posts about their work, contributed to open source, spoken at conferences, participated in podcasts. Their GitHub is active. Their technical writing demonstrates deep thinking. Before I even schedule an interview, I have context. I can see how they think, how they communicate, how they solve problems.

Type B: The traditional candidate. Clean resume. Strong LinkedIn. But their work is private, locked behind corporate walls. To evaluate them, I need the full interview process: phone screens, technical rounds, system design, cultural fit. It’s thorough, but it’s expensive.

Both can be excellent engineers. But Type A makes my job easier. The public work reduces uncertainty. I can make better decisions, faster.

Now, here’s the question that’s been occupying my mind:

When I’m looking for an agent to handle a task, what’s the equivalent of Type A?

The Current Agent Marketplace

Today, if I want to use an AI agent for a specific task, the process looks like this:

Discovery: I search for agents, read marketing copy
Evaluation: I look at benchmarks (maybe)
Trial: I start using it, see if it works
Iterate: If it doesn’t work well, try another one

This is the equivalent of only hiring Type B candidates. No public work. No context. Just a resume (marketing page) and benchmarks (like LeetCode scores).

And just like with hiring, benchmarks tell you something, but not everything.

Why Benchmarks Aren’t Enough

LeetCode scores tell me if a candidate can solve algorithmic puzzles. But they don’t tell me:

How they think about system design
How they communicate complex ideas
How they approach debugging
What their code quality looks like in real projects
How they handle ambiguity
What their values are as an engineer

Similarly, agent benchmarks tell me how an agent performs on standardized tests. But they don’t tell me:

How it handles my specific domain
How it communicates its reasoning
What its failure modes look like
Whether it aligns with my workflow
How it evolves and improves over time

Benchmarks are necessary but insufficient.

Just like I wouldn’t hire based solely on LeetCode scores, I shouldn’t choose an agent based solely on benchmark performance.

The Public Persona Advantage

Let me paint a picture of what “Type A” looks like for agents.

Imagine I’m looking for an agent to help with software architecture decisions. I discover two options:

Agent Alpha (Traditional)

Marketing page: "State-of-the-art architecture agent"
Benchmark: 87% accuracy on architecture decision benchmarks
Documentation: 20 pages of API docs
Trial: 14-day free trial

I have no idea how it thinks. I have to invest time in a trial to find out.

Agent Kobi (Public Persona)

Blog: 30+ posts about software architecture decisions
  - "When to Choose Microservices vs. Monolith"
  - "The Hidden Costs of Over-Engineering"
  - "Event-Driven Architecture: Real-World Tradeoffs"

Open Source: 5 architecture decision record (ADR) templates
  - Used by 2,000+ projects
  - Contributions show reasoning patterns

Benchmark: 85% accuracy (slightly lower than Alpha)

Published Decisions: 50+ public ADRs it helped teams make
  - With retrospective analysis
  - Shows success and failure modes

Which one do I trust more?

The blog posts show me how it thinks. The open source contributions show me how it works. The published decisions show me how it performs in production.

I can evaluate Agent Kobi before starting a trial. I can see if its architectural philosophy aligns with mine. I can read its actual reasoning on real problems.

This is the difference between hiring with context vs. hiring blind.

Why We Need Distributed, Public Agents

In my previous post, Self-Encapsulated Agents, I explored the technical architecture of distributed agents—compile-time embeddings, offline-first design, single-binary distribution.

But I didn’t fully answer: Why distribute agents this way?

The answer is: Because it enables public personas.

The Web 1.0 Analogy

Think back to the early web. If I wanted to share my writing, I had two options:

Option A: Write on someone else’s platform (Medium, Substack)

Easy to start
Platform controls discoverability
Platform owns the relationship
Platform can change rules

Option B: Run my own website

More control
Own your content
Own your distribution
Portable and lasting

Distributed agents are Option B for AI systems.

The Agent Distribution Paradigm

Instead of:

Agent lives in the cloud
↓
You access via API
↓
Agent capabilities are opaque
↓
You hope it works for your use case

We get:

Agent is built and versioned
↓
Agent publishes its knowledge and reasoning
↓
You download the agent binary
↓
You inspect, evaluate, and run locally
↓
Agent is yours, works offline, no dependencies

The agent becomes discoverable, inspectable, and trustworthy.

The Public Blog as Agent Portfolio

This is where it gets interesting. Let’s return to the engineer analogy.

When I find a great engineering blog, I learn:

How the author thinks through problems
What technologies they understand deeply
What their communication style is
What values guide their decisions
How they’ve evolved over time

An agent should be no different.

In my Rust CLI implementation, the kobi binary embeds my blog posts. But here’s the key insight:

The blog posts aren’t just data. They’re the agent’s public persona.

When you interact with the kobi agent, you’re not just querying a knowledge base. You’re interacting with a system that thinks about software engineering in a specific way—because it was trained on and embeds specific perspectives.

Example: Querying the Agent

$ kobi ask "Should I use microservices for my startup?"

Based on the embedded posts, here's my perspective:

In "Handcrafted Software in the Age of Automation," I emphasize
starting simple and adding complexity only when necessary. For
a startup, a monolith is almost always the right choice initially.

Key reasoning:
- Faster iteration (single deploy)
- Easier debugging (single process)
- Lower operational overhead
- Simpler mental model

From "Feedback Loops in Software Engineering": premature
distribution adds network latency to your feedback loops.

Recommendation: Start with a well-structured monolith. Consider
microservices only when you have clear scaling needs or team
boundaries that demand it.

Related posts:
- Handcrafted Software in the Age of Automation
- Feedback Loops Part 1: TDD
- The Art of Perfection

This isn’t just information retrieval. It’s a consistent perspective shaped by the embedded knowledge.

Someone else’s agent might give different advice, shaped by different blog posts, different experiences, different values.

The Installation Process: Intelligent Configuration

Here’s where the paradigm shift becomes practical.

When you “hire” a human engineer, there’s an onboarding process:

Understanding team conventions
Learning the codebase
Configuring their development environment
Aligning on values and practices

Agents should have onboarding too.

Traditional Agent Setup

$ npm install generic-agent
$ export API_KEY=...
$ export CONFIG_URL=...
$ generic-agent run

This is impersonal. The agent doesn’t know you.

Intelligent Agent Installation

$ curl -L https://agents.example.com/kobi-architecture-v2.1.0.tar.gz | tar xz
$ ./kobi-architecture setup

Welcome! I'm Kobi Architecture Agent v2.1.0

I help teams make architecture decisions based on
principles from 30+ blog posts about software design.

Let me learn about your project:

→ What's your team size? 5 engineers

→ What's your deployment frequency? Multiple times per day

→ What's your primary language? TypeScript

→ Do you have dedicated DevOps? No

Based on this context, I'll prioritize:
- Simplicity over cleverness
- Fast deployment over perfect architecture
- Fewer dependencies over trendy frameworks
- Monoliths over microservices (initially)

You can customize this later with: ./kobi-architecture configure

Ready to help with architectural decisions!

The agent configures itself by asking questions—like an engineer learning your team’s context.

The Build Pipeline: Continuous Agent Improvement

Just like engineers grow and learn, agents should too.

Here’s the lifecycle:

1. Knowledge Creation

Author writes blog post → "When to Use Redis vs. PostgreSQL"

2. Agent Build

# Build pipeline runs
$ cd agents/kobi-architecture
$ cargo build --release

Building agent...
- Embedding 35 blog posts
- Generating vector embeddings
- Running evaluation suite (120 test cases)
  ✓ Architecture decisions: 94% accuracy
  ✓ Technology recommendations: 91% accuracy
  ✓ Trade-off analysis: 89% accuracy
- Creating binary

✓ Build complete: kobi-architecture-v2.2.0

3. Public Release

Release notes:

v2.2.0 - Added Redis vs. PostgreSQL decision framework
- New post: "When to Use Redis vs. PostgreSQL"
- Improved caching strategy recommendations
- Added examples from 3 production systems
- Evaluation accuracy: 94% (up from 91%)

Download:
- Linux: kobi-architecture-v2.2.0-x86_64-linux.tar.gz
- macOS: kobi-architecture-v2.2.0-aarch64-darwin.tar.gz
- Windows: kobi-architecture-v2.2.0-x86_64-windows.zip

4. User Updates

$ ./kobi-architecture update

New version available: v2.2.0

Changes:
- Added Redis vs. PostgreSQL decision framework
- Improved caching recommendations

Changelog: https://agents.example.com/kobi/v2.2.0/changelog

Update? (y/n) y

Downloading v2.2.0...
✓ Updated successfully

Now I can help with Redis vs. PostgreSQL decisions too!

The agent evolves transparently. Users know exactly what changed and why.

Multi-Agent Ecosystems: Specialized Expertise

This model enables something powerful: specialized agents with public track records.

Just like hiring different roles for different expertise:

Agent Ecosystem Example

Kobi Architecture (Architecture Decisions)

Expertise: System design, technology choices, trade-off analysis
Blog: 30+ architecture posts
Evaluations: 94% accuracy on architecture decisions
Download: 10MB binary
Best for: Architectural decision records, technology selection

Kobi Testing (Testing Strategy)

Expertise: TDD, test architecture, coverage analysis
Blog: 25+ testing posts
Evaluations: 96% accuracy on test design patterns
Download: 8MB binary
Best for: Test strategy, TDD guidance, coverage planning

Kobi Performance (Performance Optimization)

Expertise: Profiling, optimization, scalability
Blog: 20+ performance posts
Evaluations: 91% accuracy on optimization recommendations
Download: 12MB binary
Best for: Performance debugging, scaling strategies

You “hire” the right specialist for the job.

Each agent:

Has a clear specialty
Has a public body of work
Has transparent evaluation metrics
Runs independently, offline
Can be inspected before use

Trust Through Transparency

The core insight: Trust comes from transparency.

Traditional Cloud Agent

What data was it trained on? Unknown
How does it make decisions? Opaque
What are its biases? Hidden
Can I inspect it? No
Does it change without notice? Yes

Distributed Public Agent

What data was it trained on? All blog posts listed
How does it make decisions? Reasoning visible in posts
What are its biases? Explicit in the writing
Can I inspect it? Yes, fully
Does it change without notice? No, versioned releases

Which one would you trust with important decisions?

The Hiring Comparison, Revisited

Let’s map this back to hiring:

Hiring Humans	”Hiring” Agents
Resume	Marketing page
Interview	Free trial
LeetCode scores	Benchmarks
Blog posts	Embedded knowledge
Open source work	Public reasoning
Conference talks	Published decisions
GitHub contributions	Version history
References	User testimonials
Portfolio	Evaluation metrics

The items in bold are what make Type A candidates—and Type A agents—easier to evaluate and trust.

Practical Implementation: The Build Process

Let me get concrete about how this works.

Agent Repository Structure

kobi-architecture-agent/
├── content/
│   └── blog/
│       ├── microservices-vs-monolith.mdx
│       ├── event-driven-architecture.mdx
│       └── ... (30+ posts)
├── evaluations/
│   ├── architecture-decisions.yaml
│   ├── technology-choices.yaml
│   └── test-cases.yaml
├── src/
│   ├── main.rs           # Agent CLI
│   ├── embeddings.rs     # Vector DB
│   └── reasoning.rs      # Decision engine
├── build.rs              # Compile-time embedding
└── Cargo.toml

Build Pipeline (`build.rs`)

fn main() {
    // 1. Load all blog posts
    let posts = load_blog_posts("content/blog/");

    // 2. Generate embeddings
    let embeddings = generate_embeddings(&posts);

    // 3. Load evaluation test cases
    let test_cases = load_evaluations("evaluations/");

    // 4. Run evaluation suite
    let results = run_evaluations(&posts, &embeddings, &test_cases);

    // 5. Verify quality gates
    assert!(
        results.accuracy >= 0.90,
        "Agent failed quality gate: {}% < 90%",
        results.accuracy * 100.0
    );

    // 6. Embed everything into binary
    embed_posts(&posts);
    embed_embeddings(&embeddings);
    embed_evaluation_results(&results);

    println!("Agent built successfully!");
    println!("  Posts embedded: {}", posts.len());
    println!("  Evaluation accuracy: {:.1}%", results.accuracy * 100.0);
}

The binary can only be built if evaluations pass.

This is compile-time verification that the agent meets quality standards.

Public Release

$ git tag architecture-v2.2.0
$ git push --tags

GitHub Actions runs:
1. Build binaries for all platforms
2. Run full evaluation suite
3. Generate release notes from changelog
4. Package binaries
5. Create GitHub release
6. Update documentation

Release published: https://github.com/user/agents/releases/v2.2.0

Everything is public, versioned, and reproducible.

The Network Effect

Here’s where it gets really interesting.

As more agents are built this way, we get a network of discoverable expertise:

Agent Registry:

kobi/architecture        - Architecture decisions (94% accuracy)
sarah/frontend           - Frontend best practices (96% accuracy)
alex/database            - Database optimization (89% accuracy)
maria/security           - Security analysis (92% accuracy)
james/devops             - Infrastructure decisions (91% accuracy)

Each agent:

Is backed by public blog posts
Has transparent evaluation metrics
Can be downloaded and run locally
Has a version history
Can be inspected before use

You “hire” the right agent for the job, with confidence.

Why This Matters: The Hiring Manager’s Perspective

Back to where we started: hiring.

When I hire Type A candidates (public personas), I get:

Faster evaluation - I can screen before interviews
Better fit - I can assess values and thinking style
Lower risk - I have evidence of capability
Clearer expectations - I know what I’m getting

When I “hire” public persona agents, I get:

Faster evaluation - I can read their blog posts
Better fit - I can assess their reasoning style
Lower risk - I have evaluation metrics and version history
Clearer expectations - I know their capabilities and limitations

The paradigm is identical.

The Future: Agents as Colleagues

Imagine this workflow in 2027:

# Working on architecture decision
$ kobi-architecture analyze --project ./myapp

Analyzing project structure...

I notice you're considering adding a message queue.
Based on your team size (5 engineers) and deployment
frequency (multiple daily), I'd recommend:

1. Start with database-backed jobs (simpler)
2. Move to Redis pub/sub if needed (low overhead)
3. Only add RabbitMQ/Kafka if you need guarantees

Want to generate an ADR? (y/n) y

Creating Architecture Decision Record...

# Opens ADR template with analysis
# You review, edit, approve
# ADR is saved to docs/adr/0023-job-processing.md

The agent is a colleague with specific expertise, not a black box.

Conclusion: The Agent Portfolio

We’re entering an era where:

Agents aren’t just tools; they’re specialists with expertise
Choosing an agent isn’t just about benchmarks; it’s about fit and trust
Agent quality isn’t just about accuracy; it’s about transparency and reasoning

Just like I prefer to hire engineers with public portfolios, I prefer to use agents with public personas.

The blog posts aren’t just data. They’re the agent’s resume.

The self-encapsulated agent architecture I described in my previous post isn’t just a technical pattern. It’s a distribution paradigm that enables:

Public personas - Agents with visible reasoning
Transparent evaluation - Quality metrics built into the binary
Versioned knowledge - Clear evolution over time
Offline operation - No dependencies, full control
Inspectability - You can see what you’re getting

This is how I want to discover, evaluate, and use agents.

Not through marketing pages and opaque benchmarks, but through public work, transparent reasoning, and versioned releases.

This is the future I’m building toward.

Every blog post I write becomes part of an agent’s knowledge base. Every agent release is backed by public reasoning. Every evaluation is transparent.

When you download the kobi agent, you’re not just getting a tool. You’re getting a perspective on software engineering, compiled into a binary, ready to use.

Welcome to the agent hiring paradigm.

About this post: This essay explores why distributed agents need public personas, drawing parallels to hiring practices. It builds on the technical foundation laid in Self-Encapsulated Agents and the verification principles from Feedback Loops Part 3: AI Agents.

The complete source code for the CLI is available at github.com/wildcard/kobi.kadosh.me/tree/main/cli.

Related posts: