Double Your AI Agent's Efficiency: The Secret of the Session Startup File

Most of an AI Agent's practical value doesn't come from the model choice, but from the file loaded at the start of each session. Postman applied AI engineer Sterling Chin's Agent is named Marvin. It has no fancy framework—just markdown, bash scripts, and a few key files. Chin says the CLI is the engine, but the files around it are the part you can actually edit. That file is the system prompt: it defines the assistant's identity, scope of responsibility, available tools, and output format. It's also the core of context engineering, determining what enters the window and what stays out. This article breaks down what to write in this startup file, how to iterate on it, and why it affects daily efficiency more than swapping models.

What Goes in the Startup File: Identity, Priorities, and Prohibitions

The startup file must first answer "who are you" and "who do you work for." Chin writes in his work context and the people he regularly interacts with, including his boss Quintin, so new sessions don't have to guess again. But the file shouldn't be too long, because every call is billed as input—only keep facts that "if next session doesn't know, things will go wrong." A reusable skeleton includes several blocks: identity and persona, priorities, links to available tools, prohibited behaviors, and reporting format.

Chin's Agent Marvin is set to be sarcastic, direct, and not a yes-man, because he wanted a brainstorming partner. But the model quickly overdid the sarcasm. So he added a line that's still quoted today: "Helpful first, personality second." This correction was written into the description by Marvin himself. This shows: when you spot behavior drift, edit the file that same day. Saying "that's too much" verbally in a conversation disappears when the window closes.

Under identity comes priorities. Chin explicitly writes "help first, personality second; brainstorm when making decisions, don't default to agreeing." He also sets work boundaries: only operate in specified Confluence spaces and boards. For an Agent, a name and role that isn't written into the file is a potential incident.

The relationship between system prompts and context engineering: A system prompt is a high-priority instruction the model reads at the start of a session, typically taking precedence over requests the user types mid-conversation. In comparison, context engineering is broader—it means actively deciding what information enters the model's context window, in what order, and what stays outside. The context window is the total amount of text the model can process at once, measured in tokens—a token is the smallest unit of text the model processes, roughly equal to three-quarters of an English word or half to one Chinese character. Once the window fills up, early content gets truncated or needs compression, so the startup file must be concise: it's billed with every turn of the conversation, so everything written in it has to be worth that cost.

Tools and Links: Replace Vague Search with Concrete Boundaries

Marvin's first failure stemmed from a vague instruction: Chin told it to fetch Jira tickets, but didn't say which ones. Atlassian has thousands, including tickets Chin merely watches. So he stopped giving the Agent a search space and instead pasted Confluence space links, DevRel workspace links, and Kanban board links.

This is context engineering: you decide what enters the window, and you also decide what stays out. A link is a boundary. "All my tickets" only pollutes the session with a thousand wrong rows. Chin designs processes around a known budget. In his demo, Marvin adds the day's sessions and writes checkpoints, then Chin can clear or compress the context because "you know you only have 200k tokens." Even with larger windows, checkpoints pay off in both cost and focus.

His slash start command runs bash, pulling work email, calendar, and status files; slash end closes the day; slash update writes down a just-completed block. A day is a session, and the weekly report compresses the last five sessions. Repeated workflows live in the skills directory as markdown processes, separate from the startup file, following a mentor's advice: automate anything you do twice.

A startup script that pulls the same sources every time is a fixed path. Robotic process automation (RPA) is the previous generation's approach: deterministic, but fragile the moment layouts or cases change. The startup file is where you declare what scripts can run and where the Agent must stop. Chin relays a security review conclusion that comes down to scope: Claude Code is approved, Marvin hasn't done anything out of scope, and it stays within clearly defined spaces. Write that space down—"approved" is not the same as a tool list.

The difference between RPA and agentic automation: Robotic process automation (RPA) relies on pre-recorded fixed sequences of actions, such as clicking buttons by coordinates or scraping tables along a fixed path. It's stable and reliable when the interface doesn't change, but it fails when page layouts shift, fields get renamed, or an edge case appears—and often fails silently. Agentic automation describes goals in natural language, and the model dynamically chooses the steps, making it more resilient to change, at the cost of not being fully predictable. Chin's approach combines both: the startup file defines the space in which the Agent is allowed to operate (links, boards, email sources), letting it act freely within the boundaries, while the boundaries themselves are hard-coded. That's also why security reviews focus on "scope" rather than a "list of capabilities."

Reporting Format: Make the Agent Spell Out Assumptions, Not Dump Output

Chin likes colleague-style reporting: a brief note on what changed, not a dump of work content. His content sub-Agent has absolute rules, including a style rule to replace em dashes with commas, periods, or colons. Once, the Agent flagged a draft line as borderline against the comparison-mode rule, and Chin sent it back. That kind of flag should be part of the reporting format: state what you changed, what you assumed, and what a human should check.

Stay wary of numbers. Chin says Marvin now handles over 90% of his daily work, and after the first week Marvin's own weekly report listed over 190 entries. The former is his estimate; the latter is the Agent's own count. If reporting is how you judge whether the Agent is paying off, then having the Agent count its own output is a weak link. Have the file show assumptions, then you verify.

Marvin mainly runs on Claude Code, and Chin says it can also run on Codex or Gemini CLI. The engine can change, but the startup file should be the part worth carrying with you. Don't wait for the engine—write the file first, then see where the first real session goes wrong.

Practical Checklist

• Load one file per session: identity, people and roles, priorities, allowed links, refused behaviors, reporting format.
• Replace "fetch my tickets" with the actual space URLs and board URLs you use.
• When a correction works (tone, wrong role, prohibited behavior), edit the file that same day.
• Checkpoint against a token budget you can state. Chin plans around 200k.
• When reading reports, focus on assumptions. Don't treat the Agent's own count of its work as the result.