jhgaylor

My agents need three verbs to help me write code: plan, implement, verify. Planning happens locally with the model and my issue tracker. Implementing happens across a fleet of coding agents. Verification has been the painful one. I ended up using GitHub Actions as my trusted environment for testing untrusted code, which works but is miserable ergonomics for an agent: batch execution, a minutes-long feedback loop, and no way to poke at a failure interactively. Unfortunately, verification is the step where the agent needs to iterate quickly.

To me, the interesting part isn't the isolation, RuntimeClass has given us gVisor/Kata pods for years. It makes it easy to deploy this new type of workload where an agent claims a pre-warmed sandbox, gets a prod-like environment with a stable identity, it can hibernate when idle and be thrown away when it has served its purpose.

Replacing CI for the verify step doesn't seem to be the marquee use case, but I'm going to set it up and try it.

This is at the bottom of section 8

> The Large Language Model MUST NOT have access to an agent's credentials or to credentials that may be needed to access tools and services. This prevents the Large Language Model from using, exposing, or being manipulated via prompt injection into disclosing the credentials.

I knew this but I just went ahead doing it wrong anyway. As a stop gap I gave all my secrets handles so the LLM and I could discuss them but I am just pretending that my agent is trustworthy. We have some big names here so hopefully there is better tooling in our future.

I'm Jake. I'm a product minded startup engineer. I'd love to explore how I can help your org ship faster and use data to drive product development.

Location: Cary, MS

Remote: Yes

Willing to relocate: Yes

Technologies: AI Product Engineering, Data Driven Product Development, Kubernetes, AWS, Polyglot Programmer

Résumé/CV: https://jakegaylor.com

Email: jhgaylor@gmail.com

I am not a particularly good writer, so I started using llms to help me write. At first that was by having the llm convert my rough draft into something ready for editing. As I edited a bunch of this work I found it still wasn’t something I wanted to put my name on.

Now I use llms to help me research, outline, refine vocabulary and grade my work but also have stopped letting it speak for me. I’m much happier with the result.

MCP is a new protocol from anthropic to standardize sharing tools and context with LLMs. Before, the tool calling api from openai was standard but tool makers all built their own mechanisms for defining and sharing tools.

It's a bit of a stretch but MCP is to LLM enabled applications what REST is to web applications.

What was happening before was if you built tools using langchain, you'd have to rewrite them for crewai, cursor, etc. Now, we have a way to share tools, resources, and prompts with applications built using different frameworks.

I was trying to find a way to thank xpe more privately but this is evidence I should just go ahead and do it. So, thank you too.

Thanks xpe, I appreciate you jumping in here. I was struggling to find the words here and I think you did a wonderful job both championing the intent of the post as well as articulating why I found it difficult to engage. You've given me tools to use going forward.

I ended up building the first couple of iterations of this tool just to stop entering the same information into Claude for every new conversation.

By connecting an assistant to a job searching api, a database, and context about myself I am able to create a prompt such as "find interesting jobs for jake. maybe something in the ai space?" and in a few minutes I can browse a curated list of potential job matches.

By connecting the assistant to text to speech and speech to text tools and context about myself I can provide a the job description in my prompt and request the assistant play the role of an interviewer. This has been much nicer than practicing in the mirror.

I think that for the next few weeks/months that a hiring team connecting to my mcp server will play out well for me but I think you're in the right ball park. It will be because I was able to show that I can extract value from technology.

My github has several repos that might help you get started if you're working in Typescript or Dart. This one for example should get you spun up with the whole stack pretty quickly https://github.com/jhgaylor/example-candidate-mcp-server.

> the `candidate-info://website-text` has a bit of marketing puffery like we don't usually see on resumes. I'm wondering whether that's intended to influence the AI tool behavior.

I actually wrote the marketing for the humans. That site predates this ai native resume. My thinking is that by putting a little sell into my site I can show off another aspect of my skillset. I used to have a standard bio site with a portfolio but it was a wall of text and needed a refresher.

> As a simpler solution

llms.txt seems to work pretty well. I am sure there are ways to increase the quality of an llms.txt but I started by simply joining all the text data I already had together and asking an llm to make an llms.txt out of it. From there I've been "manually" editing it. Often with Claude's help.

> It could be under a `/.well-known/` URL

I am hoping we start to see a lot more use of this. We already have a pretty good set of tools to do discovery so let's use them.

That's what I mean but I wouldn't represent it as being me the human speaking. We can just upgrade from text to text to speech to speech (or any mixture) while still using the LLM. And for style, I can use my voice instead of Microsoft Sam.

I think if you write the first blog post about this you get to name the law.

Sort of ironic given I wrote an interface to a robot, but I hate that robots are going to destroy this space, or rather, never give it space to exist.

I think even if no hiring manager ever connects to my mcp server I will still find plenty of value from this tool. I can connect hirebase.org and notion.com and my mcp and get claude to create a database of interesting jobs that might be a good fit for me. I can connect Speech to Text (and Text to Speech) and do mock interviews. I can import a job description and a couple of cover letters and get a customized letter for this job that gives me something other than a blank page to start with.

It's still a little rough around the edges but here is a repo I made to make it easier to get started with your own version.

https://github.com/jhgaylor/example-candidate-mcp-server

Here is a repo that should make it pretty straightforward to get started if you are familiar with express. It is the code behind my mcp server but ready to tweak for you. https://github.com/jhgaylor/example-candidate-mcp-server

The standard PDF resume is optimized for the human to read. The information density there is pretty low. Take a look at https://ai.jakegaylor.com/llms.txt and compare that to https://jakegaylor.com/JakeGaylor_resume.pdf

Now we can spend our time more on the content and less on the presentation.

Another benefit of using MCP is the LLM can request subsets of the context as it deems them valuable instead of preloading all of the context head of time. I also offer a contact tool when you use the hosted server because I can hide away my email credentials and expose a way for the LLM to send me an email.

My intention with that example was for them to explore my public work but with MCP I can hide my github PAT away on my server and let their assistant explore my private work.

I will make a better example text there, thanks. I'd much rather they explored my statbot repo anyway :)

I think the llms.txt is probably 80% of the value for 20% of the effort. I made it because MCP still isn't super approachable. However, with MCP I can offer more value. I can let you contact me directly from your assistant app. I can send you recordings of "me" answering your questions.

Claude Desktop just added support for remote servers this week. They've got it locked behind a pretty big paywall for now but I'm sure it'll make it's way to the standard plan. Others will come along. MCP is ~6 months old. There will be public clients everyone knows (chatgpt, claude) and there will be private clients (recruiter tools) that can consume those endpoints before long.

Hey Thomas - I hadn't seen your new server yet. I did migrate over to json resume as a part of building all this out. It works really well with LLMs. Iterating on it was a breeze compared to previous time's i've tried to dial in my resume.

Underneath this site is a package to make this easy to spin up for anyone. https://github.com/jhgaylor/node-candidate-mcp-server

I was thinking about spinning up a site to let folks deploy their own candidate MCP servers, it just needs a configuration blob. I wonder if we can tie it in with resume.json gists some way.

The standard PDF resume is optimized for the human to read. The information density there is pretty low. Take a look at https://ai.jakegaylor.com/llms.txt and compare that to https://jakegaylor.com/JakeGaylor_resume.pdf

Now we can spend our time more on the content and less on the presentation.

You can already use claude desktop, upload your resume, point it to your website, paste in some stuff from linkedin and output an llms.txt. You can get 80% of the way with just a couple of clicks.

I think I feel ya on some level but I also think that when the process is refined it will be much less exhausting to update our resumes with the help of an LLM. Underneath this tool is just consuming the data I already present to the world through my website, resume, linkedin, and github.

If LLMs are going to get used to filter candidates out of jobs (they will, lets be real) then it is going to happen regardless of if a candidate makes a tool that explicitly provides their data in an LLM friendly format or not.

Resumes are already being run through a machine. We know what the next generation of machine looks like, so now as candidates we can put our best foot forward.

Discovery for MCP is still an unsettled question. An adjacent protocol, A2A, has proposed using /.well-known for discovery. At the rate things are moving this won't be a problem for too much longer.

But yes, currently, you still need to read the docs to know if/where on my server you can find an MCP endpoint.

I think it would be a pretty solid improvement over crawling linkedin profiles. As candidates get better mcp servers they will be able to provide their data from where ever they choose to store it.

As discovery mechanisms for mcp and a2a get sorted, I think that we will see a new class of tools for hiring teams to find and evaluate candidates.

The bulk of the server today is just context (and tools to get the context). I offer a contact tool when you use the hosted server because I can hide away my email credentials and expose a way for the LLM to send me an email.

Future tools I have in mind include taking a job description and returning a cover letter and sample interview.

Another benefit of using MCP is the LLM can request subsets of the context as it deems them valuable instead of preloading all of the context head of time.

Yes! Sorry. MCP is a new protocol from anthropic to standardize sharing tools and context with LLMs. Before, the tool calling api from openai was standard but tool makers all built their own mechanisms for defining and sharing tools.

It's a bit of a stretch but MCP is to LLM enabled applications what REST is to web applications.

I made my llms.txt by asking Claude to generate it from my resume and website.

You can run your own version pretty easily if you can spin up an express server. I haven't dialed in the readme yet but this package offers all the mcp functionality provided by my server https://github.com/jhgaylor/node-candidate-mcp-server . You basically just need to provide a configuration object describing yourself https://github.com/jhgaylor/ai-jakegaylor-com/blob/main/src/...

Claude Remote MCP uses SSE so you'll need to bind the sse handlers to express.

However, SSE is deprecated so you might also want to bind the modern http endpoints. You can do both in the same app.

I was sure it would be off the island somewhere so I looked it up. There are many depots around the boroughs and they seem to handle their servicing internally there.

There is one not far off of Times Square.

The first thing that comes to my mind is lock-in. if you push the application to Heroku and "it just works" then when you need to deploy it somewhere else you still have that hurdle to cross. Heroku's pricing adds up quickly.