--- title: "The Agent Hiring Paradigm: Why Distributed Agents Need Public Personas" description: "When I hire an engineer, I look for their blog posts, open source contributions, and public work. Why should hiring an AI agent be any different? Exploring the rationale behind distributed, discoverable agents with public personas—and why this matters for the future of autonomous systems." date: 2026-01-08T00:00:00.000Z author: "Kobi Kadosh" url: https://kobi.kadosh.me/blog/2026-01-08-agent-architecture-rationale-hiring-paradigm category: "Developer Philosophy" tags: ["AI Tools", "Agents", "Software Engineering", "Automation", "Software Craftsmanship", "Developer Philosophy"] --- # 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: 1. **Discovery**: I search for agents, read marketing copy 2. **Evaluation**: I look at benchmarks (maybe) 3. **Trial**: I start using it, see if it works 4. **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) ```text 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) ```text 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](https://kobi.kadosh.me/blog/2026-01-07-self-encapsulated-agents-rust-cli), 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: ```text Agent lives in the cloud ↓ You access via API ↓ Agent capabilities are opaque ↓ You hope it works for your use case ``` We get: ```text 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](https://github.com/wildcard/kobi.kadosh.me/tree/main/cli), 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 ```bash $ 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 ```bash $ 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 ```bash $ 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 ```text Author writes blog post → "When to Use Redis vs. PostgreSQL" ``` ### 2. Agent Build ```bash # 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 ```diff 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 ```bash $ ./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) ```text 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) ```text 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) ```text 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 ```text 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 ```text 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 ```text 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`) ```rust 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 ```bash $ 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**: ```text 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: 1. **Faster evaluation** - I can screen before interviews 2. **Better fit** - I can assess values and thinking style 3. **Lower risk** - I have evidence of capability 4. **Clearer expectations** - I know what I'm getting When I "hire" public persona agents, I get: 1. **Faster evaluation** - I can read their blog posts 2. **Better fit** - I can assess their reasoning style 3. **Lower risk** - I have evaluation metrics and version history 4. **Clearer expectations** - I know their capabilities and limitations **The paradigm is identical.** ## The Future: Agents as Colleagues Imagine this workflow in 2027: ```bash # 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](https://kobi.kadosh.me/blog/2026-01-07-self-encapsulated-agents-rust-cli) isn't just a technical pattern. It's a **distribution paradigm** that enables: 1. **Public personas** - Agents with visible reasoning 2. **Transparent evaluation** - Quality metrics built into the binary 3. **Versioned knowledge** - Clear evolution over time 4. **Offline operation** - No dependencies, full control 5. **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](https://kobi.kadosh.me/blog/2026-01-07-self-encapsulated-agents-rust-cli) and the verification principles from [Feedback Loops Part 3: AI Agents](https://kobi.kadosh.me/blog/feedback-loops-part-3-agents). The complete source code for the CLI is available at [GitHub.com/wildcard/kobi.kadosh.me/tree/main/cli](https://github.com/wildcard/kobi.kadosh.me/tree/main/cli). **Related posts:** - [Self-Encapsulated Agents: Building Autonomous CLI Tools in Rust](https://kobi.kadosh.me/blog/2026-01-07-self-encapsulated-agents-rust-cli) - [Feedback Loops Part 3: AI Agents](https://kobi.kadosh.me/blog/feedback-loops-part-3-agents) - [Vibe Engineering: Orchestrating Instead of Typing](https://kobi.kadosh.me/blog/2025-12-06-to-vibe-or-not-to-vibe)