I have been using Hermes to help ship the site you are reading now.

Not in the vague sense of asking an AI tool to suggest copy and then pasting the answer into a CMS. I mean the more practical version: opening issues, reading the repository, checking the content schema, creating branches, changing files, running builds, scanning for mistakes, preparing pull requests, and leaving enough context for me to review the work later.

That changes the shape of the work. The agent is not sitting beside the workflow. It is inside it.

For a long time, most AI use felt like a text box. I would ask for a draft, a summary, a regex, or a second opinion. Useful, but still separated from the place where the work actually happened. Hermes has been moving in a different direction for me: it is becoming an execution surface that can move between memory, tools, repositories, projects, notes, and publishing tasks.

That sounds larger than it feels day to day. In practice, it feels like having a very literal teammate that needs clear instructions, good boundaries, and regular review.

From prompt to operating layer

The biggest shift is not model quality. It is the connection between context and action.

If I ask a normal chatbot to help with a journal post, I still have to provide the brief, explain the site structure, copy the result, check the route, remember the image requirements, run the build, and turn the work into a PR.

With Hermes, the work can start from the system where the task already lives. A GitHub issue can contain the brief. The repository can contain the content schema and existing tone. A project board can show the status. Notes can provide background. The agent can inspect the files, make a change, validate it, and hand me a reviewable artifact instead of a paragraph of advice.

That is the part I care about: fewer loose pieces between intention and execution.

I am not trying to remove myself from the process. I am trying to remove the mechanical gaps that make good work slower than it needs to be.

The workflow I keep coming back to

The pattern is simple enough that I now use it across different kinds of work.

A simple Hermes workflow loop from human judgment to tools, repos, notes, cron jobs, and review.

It usually starts with a note or an issue. I write down what I want, why it matters, the constraints, and the acceptance criteria. That may be a content brief for this site, a product task, a QA pass, or a content operations item for IrishTalents.

Then Hermes does the parts that are easy to describe but annoying to coordinate:

  • inspect the repository before changing anything;
  • understand the existing schema, routes, and naming patterns;
  • create a branch for the work;
  • make focused edits instead of mixing unrelated changes;
  • create or update assets when the task needs them;
  • run the build and validation commands;
  • scan for banned language, secrets, or formatting issues;
  • open a draft PR and connect it back to the issue.

This matters because many real workflows fail in the handoffs. A good article still needs frontmatter. A useful campaign still needs an owner, a status, a review step, and a publishing decision. A code change still needs a branch, a diff, a build, and a PR. The agent helps by carrying the work across those seams.

For the personal-site redesign, this has been especially useful. The site is not just a static portfolio anymore. It is becoming a place for journal posts, project pages, services, and founder notes. That means content and code are close together. A small editorial decision may touch routes, images, metadata, page structure, and QA.

For IrishTalents, the pattern is similar but applied to marketing and content operations. The public product is about helping people find jobs in Ireland. Around that product, there are recurring content ideas, landing page improvements, SEO checks, social posts, and follow-up tasks. Hermes is useful when those pieces need to move through the same system instead of living as scattered reminders.

What I delegate

I am getting more comfortable delegating larger chunks of work to agents, but only when the task has enough shape.

I do not want Hermes inventing a strategy for me. I do want Hermes to turn a clear strategy into working steps.

A good delegated task includes:

  • the desired outcome;
  • the audience;
  • the constraints;
  • examples of existing work;
  • what must not be exposed;
  • how the result should be validated;
  • what should stay as a draft for human review.

When those pieces are present, I can delegate more than a small prompt. I can delegate a workflow.

That distinction is important. Asking for text gives you text. Asking for a validated branch gives you something closer to progress.

What I keep human

The more I use agents, the more strongly I feel that human judgment needs to be explicit.

Taste stays with me. So does strategy. So does the final call on publishing. Hermes can produce a draft, but I still decide whether it sounds like me, whether it is useful, whether it reveals too much, and whether it deserves to exist on the site.

Privacy also stays non-negotiable. An agent that can work across repositories and tools needs boundaries. It should not expose tokens, private client details, sensitive local paths, or internal strategy that was never meant to be public. The point is not to make everything available to an agent. The point is to give it the right context for the job.

I also keep the responsibility for review. A build passing is not the same as a piece being good. A clean diff is not the same as a good product decision. An automated scan can catch some problems, but it cannot replace judgment about tone, timing, or usefulness.

This is where I think a lot of agent work becomes more realistic. The best version is not autonomy everywhere. It is delegation with review designed into the loop.

Where this is going

I do not think of Hermes as a replacement brain. I think of it more like a personal operating system for work that crosses tools.

That operating system needs memory, because many tasks depend on context. It needs access to tools, because work has to happen somewhere. It needs project awareness, because priorities matter. It needs cron workers, because some tasks are recurring. It needs PRs and drafts, because review should be part of the system, not an afterthought.

Most of all, it needs a clear relationship with the human using it.

For me, that relationship is becoming straightforward: I decide what matters, Hermes helps move the work, and I review what comes back.

That is already enough to change how I build.