Treat Me Like an Agent

Mon, 11 May 2026 00:00:00 +0000

A few weeks ago, one of my PhD students needed Google Cloud credits for a project. The credits live on my billing account, so they needed me to provision the access. The message they sent me had the project name, the rough budget, the IAM role they needed, the exact email address to add — and at the bottom, a small numbered list of steps for me to follow in the Cloud Console. Open the dashboard. In the left sidebar, click X. Find the project named Y. Add member, paste this email, assign this role. From message to provisioned access took about ninety seconds.

A couple of weeks later, a different student needed essentially the same thing — different project, structurally identical ask. They sent me a one-liner: “Hi Professor, could I use some of your Google Cloud credits for my project?”

I could see the whole back-and-forth this would require — which project, how much, what role, what email, where I would need to click — and I didn’t want to run it. So I wrote back and told them to go ask the first student how to prepare a request like this, and to come back when they had.

That was the moment something clicked. The thought has been sticking with me ever since:

I’m an LLM agent for my students. The value I produce for them is bounded by the prompt they give me.

Same model, different prompts

Anyone who has spent serious time with large language models knows this in their bones: the same model with two different prompts can produce wildly different outputs. The literature calls this prompt engineering, and lately context engineering — the discipline of constructing an input that gives the model the best shot at the answer you actually need.

The students who get the most out of me are doing exactly this, whether or not they would describe it that way. They tell me what they want, supply the context, anticipate my follow-up questions, and remove every unit of friction from the path between their need and my action. They are, in effect, designing a careful prompt for a model whose attention they only have in limited windows.

This isn’t about politeness or formality. The one-liner I got was perfectly polite. It just under-prompted me. It left me to assemble the context myself, and the result is the same thing that happens when you give an LLM a vague instruction: more turns, more clarifications, more compute wasted on both sides — or, if the model has limited patience that afternoon, a redirect back to someone who can teach you to prompt better.

A second example

The contrast did not show up only in that one exchange. Around the same time, I asked both students to write a short retrospective on their recent paper submissions. I wanted to know what they had learned and what we should do differently next time.

The first student — the one who had carefully prepared the credit request — sent me a four-page PDF. It had an introduction, a section on what they had learned, a section on what went wrong, a remediation and action plan, and a short conclusion.

The second student typed a few bullet points directly into the shared Google Doc we use for meeting notes. Three or four lines. Most of what I would have wanted them to reflect on wasn’t there.

I don’t need to tell you which one I preferred. But I want to be precise about why, because it isn’t that the PDF was longer or prettier. The PDF was engineered to do a job. It anticipated the questions I would have asked, and answered them before I asked. It separated the diagnostic part (what went wrong) from the prescriptive part (what we’ll do about it), which is exactly the structure I would otherwise have had to pull out of the bullet-point version myself. It gave me leverage: I could read it, agree or disagree with specific claims, and we could spend our next meeting on the action plan instead of excavating context.

The structure of the document was the prompt.

The reciprocal half

Here is the part I want to be careful about, because the “treat me like an agent” framing only works if it cuts both ways.

I treat my students like agents too — but in a specific way that’s worth spelling out.

I am not trying to develop them into well-trained question-answerers. I am trying to develop them into something more like autonomous research agents: the kind that can frame a problem, decompose it, run the steps, decide what to escalate, and come back to me only when something genuinely needs my judgment. That is a much harder design problem than getting any single task done well. It means that a great deal of what I do — in our meetings, in the way I reply to messages, in what I sometimes refuse to answer directly — is calibrated less for the immediate response and more for the agent I am trying to grow over time.

I rewrite my own prompts often. I watch for places where a particular phrasing of mine pulls a student toward dependence rather than independence, and I adjust. The redirect I sent the second student — go ask the first student how to prepare this kind of request, and come back when you have — was a prompt too, and a deliberate one. I could have just answered the question. I did not, because the answer was not what they needed.

So when I say “treat me like an agent,” I am not asking for deference. I am pointing at a structural fact: the bandwidth between any two collaborators is narrow and expensive, and the construction of that bandwidth — the prompts in both directions — is real work that compounds over time. The students who get the most out of me are the ones doing that work on their side. The best version of me, on my side, is doing it for them.

What this looks like in practice

If you’re a PhD student, or really anyone working with a more senior collaborator, here is the version of this I wish I had heard earlier in my own career.

Your advisor is not a magic oracle. They are a model with finite context, finite attention, and a long queue of other inputs. The value you extract from them per unit of their time is a function of the prompt you hand them. Specify what you want. Supply the context. Anticipate the follow-ups. Pre-compute the parts they would otherwise have to compute. Lower the activation energy of the thing you are asking them to do.

For requests: tell them the goal, the constraints, what you’ve already tried, and exactly what you need. If there’s a UI they have to click through, walk them through it.

For deliverables: don’t hand them raw material and ask them to structure it. Hand them something already structured — even a rough outline of intro / what I learned / what went wrong / what we’ll change beats a bulleted brain dump, almost every time.

If you’ve read this far, you’re probably already the kind of person who does this. The harder move is to notice when you aren’t, and to fix that before you blame the output.

We’re all agents to each other. The good news is that prompt engineering, on both sides, is a skill you can practice.

Blog | Lei Zhang

Treat Me Like an Agent

Same model, different prompts

A second example

The reciprocal half

What this looks like in practice