Why Humble & Kind

Every few weeks a recruiter asks me what would make me move. A prospective client asks how I run the first ninety days with a new team. I answer both from memory, typing paragraphs I've typed before, hoping I phrase them close enough to what I said the last five times someone asked.

The people who actually want to know something about you, a recruiter sizing you up or a client deciding whether to hire you, don't scroll a profile. They ask a question. Right now the only way to answer is by hand, one message at a time, for as long as you're willing to keep doing it. A LinkedIn post is written once for everyone and read by almost nobody in particular. That's the gap this started from.

The half nobody built

Every login button on the web now runs on the same idea. OAuth, the connectors Slack and Notion and a hundred other tools use, the MCP servers agents are starting to plug into: all of them answer one question, what can an app or an agent read on my behalf. That direction is mature. It's also only half the problem.

Nobody built the mirror. What can another person read of you, through rules you actually set, without you sitting in the chat answering it live? That gap, not a feature list, is the reason humblekind.co exists. Plenty of people are building the pipe that lets your assistant read your calendar. Almost nobody is building the pipe that lets a stranger's assistant ask you something and get an answer you control.

A page that answers for you

What you get is a page. You write down what you actually know: lessons you'd tell someone junior, beliefs you'd defend, opinions, how you do things, where you stand on something contested, the shape of your work history. Type it by hand, import your LinkedIn export and tick what's true, or let your own assistant, Claude or ChatGPT, interview you and propose things for you to approve. Nothing lands on the page without you saying yes to the exact words.

Then you choose who gets to ask, and how much they get per topic. Anyone on the web. Anyone signed in. Only the people you invite. For each of those, a separate setting per topic: in full, roughly, a yes-or-no, or hidden entirely. A recruiter might get your hiring beliefs in full and your calendar as a rough yes-or-no. A close colleague might get all of it. A stranger on the open web might get your published lessons and nothing about who you're currently working with.

When someone asks, your page answers in your own words, quotes you directly, and shows its sources for every claim it makes. Their AI assistant can ask it too, the same way you'd ask theirs.

The one rule it stands on

Here's the part that actually took the time. My first instinct, and I'd guess most people's, was to give the model everything and tell it what not to say: don't mention salary, don't mention the client's name. That doesn't work. A prompt is not an access control list. Anything sitting in a model's context window is one well-phrased follow-up away from coming back out.

So the rule ended up stricter than a sentence in a prompt. Whatever someone isn't allowed to see is removed before the model ever reads the question, in code, not by instruction. If a fact is denied, it isn't summarized, hinted at, or referenced by accident, because it was never in the room to begin with. That piece was slower to build than everything around it, and it's the one piece that can't be a shortcut.

What it will not do

Some decisions were easier to make than to hold to. There's no composer, and there's nothing to post. No feed of you performing for an audience. No likes, no points, no streaks, no rankings, because the day a number goes up when you add a fact, you start adding facts to make the number go up, and the page stops being true. Money and health don't live in the product at all, never stored, never answered, by design rather than by a filter that might fail someday. An answer is a person's view. It says so, and it never claims to be advice.

You can see every question your page was asked and what it said back. You can delete all of it, at any time, and it's gone.

Why "Humble & Kind"

The name does two separate jobs. Humble, because the page only knows what you told it, and when it doesn't know something it says so plainly instead of making something up to sound useful. Kind, because it answers the person who actually asked, on terms you set, without ever asking you to perform for an audience you can't see.

I'd been running a version of this idea before it had a name. TinyCTO started as around eighty lessons from years of running engineering teams, wired up so other people's AI agents could ask it questions over MCP. It had exactly one setting: everything, to everyone. That was fine until I wanted to tell a stranger something different from what I'd tell a client, and something different again from what I'd tell someone I've actually worked beside. Humble & Kind began as the question of how to add a second and third setting to one flat page, and it turned into this.

It's early, and it's free to make a page. Create your page, or ask a page first to hear what one sounds like before you build your own.