Personal AI Agent Setup Guide

A useful personal AI agent is not a smarter chatbot. It is a small operating layer around your real life and work: goals, context, source-of-truth files, decisions, routines, tools, and human approval gates.

This is the individual path through the AIAM thesis: AI agents need operating systems. Start with one person, one source of truth, and one useful loop. The goal is to close the gap between “I have a smart assistant” and “I trust this system with recurring work.”

Do less at first. Make one loop useful before making the system impressive. Do not begin by connecting every app, calendar, inbox, and digital cupboard. Start by deciding what the agent is for, creating a simple git-backed knowledge store, getting one private interface working, and improving the system through real use.

This guide is opinionated on purpose. The default stack is ChatGPT for the planning interview, Codex for setup help, a git-backed Markdown knowledge store, Hermes Agent as the runtime, Railway for hosting, and Telegram as the first interface. The direct Railway path is now simpler than the original custom-deploy route: start from Railway's Hermes Agent template, which uses the official nousresearch/hermes-agent Docker image, persistent storage at /opt/data, gateway mode, and an optional dashboard.

LifeOS, GBrain, and Obsidian can all work. The important thing is the repository: a place the agent can read, update, validate, and version.

This stack is not theoretical. It comes from running a real Telegram-accessible personal agent, maintaining a git-backed LifeOS workspace, separating durable source-of-truth files from hot memory, debugging Railway webhook behavior, reconciling crons against LifeOS routines, and improving the agent through actual use. The guide keeps the repeatable setup pattern and leaves out private context, secrets, and deployment-specific details that should not be copied.

What makes a personal agent useful

A personal agent becomes useful only after it understands the shape of the operator’s goals.

Before that, it behaves like a bright helper with no filing cabinet: energetic, plausible, and occasionally holding exactly the wrong folder.

Useful structure arrives through use. Different goals need different context. Decisions need a place to land. Routines need review. Reusable procedures need to become skills.

The practical lessons:

• Goals come before automations. A cron is useful only when it reviews or advances a real outcome.
• A repo beats a memory dump. The agent needs readable files for goals, systems, tasks, decisions, routines, and reusable skills.
• Not all context deserves to be saved. Durable memory should be small, stable, and useful later.
• Approval gates create trust. The agent can draft, research, and recommend; the human approves sending, spending, publishing, deleting, pushing code, or changing production systems.
• Maintenance is the product. Usage should become better context, clearer boundaries, and better routines.

What you are building first

The first version is deliberately small. Small is how trust starts, because the bridge has to be visible before the agent gets more responsibility:

1. Operating map: why the agent exists, what it should help with first, what it must not touch, and what success looks like in week one.
2. Git-backed knowledge store: a private repo or git-tracked folder with Markdown files the agent can read and update safely.
3. Hosted runtime: Hermes Agent on Railway.
4. Private interface: Telegram.
5. Maintenance habit: a weekly review before adding more tools.

The first milestone is not “agentic everything.” It is this: send a Telegram message and receive a useful response grounded in your seed context and knowledge-store structure. Once that works, you have a real loop. Before that, you have ambition and maybe a very nice project name.

This is the personal version of LifeOS: source-of-truth structure, operating rules, routines, and approval gates that let an agent help without becoming an ungoverned memory pile.

Start personal, but notice the transferable pattern. The same operating layer that makes one person’s agent useful also explains why teams need workflow ownership, decision rights, approval gates, and scorecards before adding more AI automation. In both cases, confidence comes from the mechanism working in the open.

Use this in ChatGPT before the technical setup:

You are helping me prepare a personal AI agent and its git-backed knowledge store.

Interview me and produce a concise setup packet. Keep it practical. Do not ask for passwords, API keys, private keys, recovery codes, or secret values.

Ask about:
1. Why I want a personal agent.
2. What would make it useful in the first week.
3. My main roles, responsibilities, goals, and active projects.
4. The work I keep postponing because restarting the context is too expensive.
5. The notes or documents I can safely use as seed context.
6. What the agent is allowed to do, what it may draft, and what requires my approval.
7. What should never be stored or reused.

After the interview, create:
1. A short operating map.
2. Week-one success criteria.
3. First workflows to support.
4. Privacy and human approval rules.
5. Durable memory rules: what should be saved, where it belongs, and what should stay out.
6. A recommended git-backed folder structure for my knowledge store.
7. Starter Markdown files with brief bullet content for each file.
8. Open questions to fill in later.

The folder structure must include clear homes for:
- personal context and preferences
- goals or outcomes
- systems or projects
- tasks
- decisions
- routines or recurring reviews
- reusable skills or procedures
- inbox items that need triage

Start by asking me 5-7 questions.

Prep checklist

Before asking Codex to set anything up, make sure you have:

• ChatGPT access for the planning interview;
• Codex access on the machine where setup will happen;
• a GitHub account or another place to host a private git repo;
• a Railway account and project;
• a Telegram account and the ability to create a bot with BotFather;
• a rule that real secrets go only into Railway Variables or the right secret store, never into prompts or committed files.

Use a git-backed Markdown repository as the default. You can model it after LifeOS, organize it in Obsidian, or adapt it to GBrain. Just do not skip the durable store. A personal agent without one will drift back into chatbot behavior.

A simple first structure:

personal-agent/
  README.md
  AGENT.md
  personal/
    profile.md
    preferences.md
    constraints.md
  goals/
    current-goals.md
  systems/
    README.md
  tasks/
    next-actions.md
  logs/
    decisions.md
    routines.md
    interactions.md
  skills/
    README.md
  inbox/
    needs-triage.md

Use the planning interview output to fill the first version. Keep it short. Empty but named files are better than one giant context dump.

Viable structure options:

• LifeOS-style repo: best if you want explicit homes for personal context, outcomes, systems, tasks, decisions, routines, interactions, and skills.
• Obsidian vault in git: good if you already think in notes and want a readable local workspace.
• GBrain-backed structure: good if you want a graph-oriented personal knowledge system with agent-readable files.
• Plain git-backed Markdown: best default if you want the simplest reliable start.

The tool choice is less important than the rule: personal facts, active goals, system state, decisions, routines, and reusable procedures should not all be mixed into one memory file.

The direct path is now:

1. Open Railway's Hermes Agent Complete Setup template.
2. Deploy the service from the official nousresearch/hermes-agent image.
3. Attach a Railway Volume at /opt/data so Hermes config, sessions, memory, skills, logs, and cron state survive restarts.
4. Run the service in gateway mode. The template uses gateway run instead of launching the interactive terminal UI.
5. Keep the dashboard optional. If you enable it with HERMES_DASHBOARD=1, expose port 9119; the gateway API uses port 8642.
6. For Railway and other cloud hosts, prefer Telegram webhook mode over polling so the service can receive inbound Telegram updates through its HTTPS Railway URL instead of keeping an outbound polling loop alive.
7. Add only the provider and Telegram variables required for the first private conversation.
8. Send one Telegram test message and verify that the answer reflects your seed context.

Use this as the Codex setup prompt:

You are Codex helping me set up the first useful version of a personal AI agent.

Goal:
Walk me step by step until I can send the agent a message in Telegram and receive a useful response grounded in my git-backed knowledge store.

Stack:
- Planning interview: ChatGPT
- Setup assistant: Codex
- Knowledge store: private git-backed Markdown repo
- Runtime: Hermes Agent
- Hosting: Railway using the Hermes Agent Complete Setup template
- First interface: Telegram

Inputs:
- Setup packet: [paste the planning interview summary]
- Knowledge-store structure: [paste the recommended folder tree]
- Repo location: [GitHub URL or local path]
- Railway template: https://railway.com/deploy/hermes-agent-nousresearch

Rules:
- Keep the setup small.
- Prefer the Railway template and official Docker image over a custom Dockerfile unless there is a specific reason.
- Do not ask me to paste real secrets into chat, prompts, docs, or committed files.
- Use placeholders in templates.
- Real runtime values go into Railway Variables or the appropriate secret store only.
- Do not add email, calendar, docs, browser, CRM, or other tool integrations yet.
- Do not send messages, spend money, publish, push code, delete files, or modify production systems without explicit approval.
- Stop at the first working Telegram message before adding advanced routines or crons.

Steps:
1. Inspect the current folder or repo.
2. Create or verify the knowledge-store folders and starter Markdown files.
3. Save the seed context in the right files without secrets.
4. Open the Railway Hermes Agent template and confirm the service uses the official image, gateway mode, and persistent volume path `/opt/data`.
5. Create a short Railway variable checklist for the selected model provider, Telegram bot token, allowed Telegram user IDs, Telegram webhook URL/secret, API server key if the API/dashboard is exposed, and any optional dashboard setting.
6. Help me enter real secrets manually in Railway Variables.
7. Configure Telegram with BotFather, get my numeric Telegram user ID, and allowlist that ID.
8. Start the Railway service and check the logs until the gateway is healthy.
9. Walk me through sending the first Telegram test message.
10. If something fails, debug only the blocker to the first message.

Acceptance criteria:
- The git-backed knowledge-store location is explicit.
- Seed context is saved in readable non-secret files.
- Secret names are documented, but real secret values are not stored in prompts or committed files.
- The Railway service has persistent storage mounted at `/opt/data`.
- Telegram reaches the agent.
- The agent's response reflects the seed context.
- A short runbook explains start, stop, troubleshooting, and safe updates.

Minimal Railway variable checklist

Treat this as a checklist of names, not a place to paste real values. The template can generate an API key for you; provider and Telegram credentials still come from your own accounts.

# Hermes runtime / dashboard
HERMES_DASHBOARD="1"                     # optional browser dashboard
HERMES_DASHBOARD_HOST="0.0.0.0"
HERMES_DASHBOARD_PORT="9119"
API_SERVER_ENABLED="true"                # needed if exposing the gateway API or dashboard integration
API_SERVER_HOST="0.0.0.0"
API_SERVER_KEY="generated-in-railway"
API_SERVER_CORS_ORIGINS="*"

# Model provider: choose the one you actually use
OPENROUTER_API_KEY="set-real-value-in-railway"
# or ANTHROPIC_API_KEY="set-real-value-in-railway"
# or another Hermes-supported provider key

# Telegram
TELEGRAM_BOT_TOKEN="set-real-value-in-railway"
TELEGRAM_ALLOWED_USERS="comma-separated-numeric-telegram-user-ids"
TELEGRAM_WEBHOOK_URL="https://your-railway-domain.up.railway.app/telegram"
TELEGRAM_WEBHOOK_SECRET="generated-in-railway"
# TELEGRAM_WEBHOOK_PORT="8443"           # optional; set only if your Railway service routes to a different local port

# Optional later: if the runtime itself needs to pull a private knowledge-store repo
KNOWLEDGE_STORE_REPO_URL="git@github.com:your-org/your-personal-agent.git"
KNOWLEDGE_STORE_PATH="/opt/data/workspace/personal-agent"
GIT_AUTHOR_NAME="Your Name"
GIT_AUTHOR_EMAIL="you@example.com"

You do not need to start with a custom Dockerfile, a separate dashboard service, or a hand-built Railway wrapper. Add those only after the first Telegram loop works and you can name the problem they solve. For the exact runtime details, use the official Hermes Docker guide and Telegram guide as the source of truth.

First Telegram message checklist:

[ ] Setup packet created
[ ] Git-backed knowledge store created
[ ] Seed context saved in the right files
[ ] Real secrets kept out of prompts and committed files
[ ] Railway variables entered by the human
[ ] Telegram bot created
[ ] Allowed Telegram user ID configured
[ ] Telegram webhook URL and secret configured for Railway
[ ] Runtime starts
[ ] Telegram message reaches the agent
[ ] Agent answer uses the seed context
[ ] Runbook exists

For a deeper first-week routine, read The First Week Maintenance Routine for a Personal AI Agent.

The short version is:

1. Use it for one real task. Pick something where your goals, projects, or constraints matter.
2. Correct it immediately. When it misunderstands your priorities or boundaries, turn the correction into a better rule.
3. Save less than you think. Durable memory should be stable context, decisions, preferences, constraints, and repeated corrections — not every chat.
4. Review before adding tools. If the agent cannot handle your priorities cleanly, email or calendar access will not fix it.
5. Add crons only after the goal is clear. A weekly review, role scout, content review, pipeline-generation reminder, renewal-risk check, or expansion follow-up should exist because it advances a real outcome.

Use this weekly maintenance prompt:

Run a weekly maintenance review for my personal AI agent.

Review:
1. What real work did the agent help with this week?
2. What goals, projects, decisions, routines, or files changed?
3. What did the agent misunderstand, over-save, under-save, or route badly?
4. What context should be written to the git-backed knowledge store?
5. What context is stale, duplicated, too detailed, or no longer useful?
6. What approval boundary needs to be clearer?
7. What one improvement would make the agent more useful next week?

Rules:
- Do not save secrets.
- Ask before deleting or overwriting durable context.
- Prefer small, high-confidence updates.
- Do not recommend new integrations unless the existing loop is working.

Output:
- Recommended repo updates
- Stale context to review
- Safety or approval issues
- Suggested next small improvement
- Anything that requires human approval

Personal AI agent FAQ

What is a personal AI agent?

A personal AI agent is an operating partner grounded in your goals, durable context, source-of-truth files, routines, tools, and approval rules. It is useful because it can work from your real operating map, not because it can answer one isolated prompt.

What does a personal AI agent need beyond ChatGPT?

It needs a durable knowledge store, clear homes for decisions and routines, a safe private interface, and rules for what requires human approval. ChatGPT can help with the planning interview; the agent becomes more useful when that plan is turned into files, workflows, and maintenance habits.

Why use a git-backed knowledge store?

Git gives the agent readable context, version history, reviewable changes, and a way to separate durable facts from temporary conversation. A repo also makes it easier to recover, audit, and improve the agent over time.

How do approval gates keep a personal agent safe?

Approval gates make the boundary explicit: the agent may draft, research, summarize, and recommend, but the human approves sending, spending, publishing, deleting, pushing code, changing production systems, or storing sensitive context.

How does this connect to LifeOS?

LifeOS is the broader operating-system pattern behind this guide: typed context, source-of-truth capsules, approval boundaries, routines, and review loops. A personal AI agent is one way to operate that pattern through a conversational interface like Telegram.

When to add routines and crons

Recurring jobs are powerful, but they should be earned. A cron without a clear goal is just a recurring reminder that the operating system is still vague.

Useful crons come from goals: review the system, inspect content opportunities, check specific career work or revenue lifecycle segments, and surface follow-up actions. They should exist because the agent understands what outcome the routine serves and where the result should be routed.

Before adding a cron, answer:

• What goal does this routine protect or advance?
• What source of truth should it read?
• Where should its output go?
• Is it advisory, or is it allowed to change files?
• What requires human approval?
• How will we know if the routine is stale, noisy, or no longer useful?

Most people should start with one advisory weekly review. Add more only when the review repeatedly exposes a real recurring need. This keeps the agent growing by contact with reality rather than by accessory shopping.

Good fit signals

This is likely a fit if:

• you already use AI often but lose context across tools;
• you have goals or projects that stall because restarting the context is too expensive;
• you want an agent that remembers decisions, routines, and boundaries;
• you are willing to keep a small git-backed knowledge store;
• you care about durable memory, source-of-truth structure, and human control.

Not a fit if

This is probably not the right starting point if you want:

• a fully autonomous assistant with no supervision;
• a black-box tool that stores everything everywhere;
• a one-click product with no operating model;
• secret handling inside prompts;
• automations and integrations before basic routines are tested.