Problems on TypeSpec - Agent do today

[EMLLC-Support]

Hello all. I am having difficulty with typespec serving stale documents after compiling. I have an agent due today. Can I speak to a real person with this as I am kind of in crunch time? @sebastienlevert

[sebastienlevert]

When compiling, are you getting the generated manifest you would expect? I assume the changes you are seeing are related to the plugins / OpenAPI files? We are seeing long cache issues right now. If you want 30ish minutes, are your agents back on track?

[sebastienlevert]

There is a 8k limit on the instructions field. This is a current limitation on the platform. In this case, you might want to simplify the instructions. As connected agents are rolling out, you could, in the future, split the experience on multiple agents to achieve a similar experience with more "specialized" agents. This is not yet fully rolled out and not available in TypeSpec just yet.

[EMLLC-Support]

I'm condensing the script as we speak. I condensed it too much before and it broke everything. I'm cutting out functionality to meet my deadline.

[EMLLC-Support]

Hi @sebastienlevert
I've made some progress and feel I'm in a good place with my offering submission process. Thanks for your help.

Separate question for you. I want my agent to be included in not just teams but all of M365 apps (i.e. Outlook, word, excel, sharepoint, etc). I get the below listed error when I try to upload a v1.26 manifest into the admin center upload agent screen?

The manifest version provided is unsupported. Supported types are: 1.13, 1.14, 1.15, 1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22, 1.23, 1.24, devPreview, m365DevPreview

Is manifest.json version 1.26 supported in marketplace publications yet?

[sebastienlevert]

I don't think so. The latest is 1.24.

https://learn.microsoft.com/en-us/microsoft-365/extensibility/schema/?view=m365-app-1.24#whats-new-in-manifest-version-124

[EMLLC-Support]

Thanks for your response @sebastienlevert . Trying to squeeze a lot into tiny instruction block packages lol. I look forward to figuring it out. Have a great weekend!

[EMLLC-Support]

Hi @sebastienlevert . I have a question for you.
I have integrated authentication into my apim backend. My pipeline works properly. The challenge is my agent is not passing the user's proper email. It is giving me another users email when i test. My exact instructuion is as follows:
userId: the signed-in user's email address in UPN format (e.g., [email protected]). Do not use display name or aliases

Is this instruction acceptable?

[sebastienlevert]

As a way to authenticate the user? You should not use that. You should probably use the identity coming from the user in your backend service.

[EMLLC-Support]

As always, thank you for your response, @sebastienlevert . I'll have my gateway setup to handle tokens now. Also, is there a group in the community who answers these types of questions, or should I continue to ping you? I truly appreciate your responses, so I want to be careful not to hit you with too many questions.

[sebastienlevert]

For now, this is the right place!

[EMLLC-Support]

More questions to follow :-)

[EMLLC-Support]

Ok @sebastienlevert. First off happy holidays to you. I hope you are enjoying your break.

As far as the next stage of questions go, I'm at the point where my backend workflow engine is fully implemented and working correctly. The next step is stabilizing the stateless front‑end layer. The full pipeline is wired end‑to‑end, but the agent still isn’t calling the backend correctly during API calls.

To fix this, I’ve been updating the TypeSpec‑generated *-apiplugin.json files so the agent binds to the correct OpenAPI operations. The problem is that every time I publish the agent, those updated plugin files get overwritten by the TypeSpec emitter.

What’s the correct way to ensure my modified plugin files are preserved and actually used at publish time? Should I be customizing the emitter, overriding the generation step, or placing the updated files somewhere else in the build pipeline?

[EMLLC-Support]

@sebastienlevert

As a follow‑up, here are the exact details of my setup so you can see where the problem is happening.

Schema Version I'm Targeting
All of my Copilot plugin files are using the v2.3 schema:
https://developer.microsoft.com/json-schemas/copilot/plugin/v2.3/schema.json

File Paths Involved
These are the plugin files that I manually update after TypeSpec generation:

Code
/dist/stateactions-apiplugin.json
/dist/responseactions-apiplugin.json
/dist/workflowactions-apiplugin.json
/dist/fworkflowapi-apiplugin.json
Each of these references a corresponding OpenAPI file:

Code
/dist/stateactions-openapi.yml
/dist/responseactions-openapi.yml
/dist/workflowactions-openapi.yml
/dist/workflowapi-openapi.yml
And the declarative agent manifest that loads these plugins is:

Code
/dist/declarativeAgent.json
My Build Workflow
Here’s the sequence I’m using:

I run the TypeSpec emitter to generate the OpenAPI files and the initial *-apiplugin.json files.

I manually update the generated plugin files to match the v2.3 schema rules (since the emitter still outputs older-style plugin definitions).

I publish the agent using the Teams Toolkit / Copilot publish pipeline.

During publish, the updated plugin files get overwritten by the emitter output, and the agent reverts to the incorrect plugin definitions.

As a result, the agent cannot bind functions to OpenAPI operations and falls back to the generic “Workflow Actions” stub instead of calling my backend.

The Issue
I need a way to ensure that the corrected v2.3 plugin files are preserved and actually included in the published agent package. Right now, the TypeSpec emitter overwrites them every time I publish, which breaks the API binding.

My Question
What is the recommended approach to ensure that the corrected plugin files are used during publish?
Should I:

override the emitter output,

customize the emitter configuration,

move the plugin files to a different directory,

or modify the build pipeline so that my corrected versions replace the generated ones before packaging?

Any guidance on the right pattern for preserving custom plugin files in a TypeSpec‑driven Copilot agent would be extremely helpful.

[sebastienlevert]

Please provide a repro, I can't debug this. The version of the manifest referenced shouldn't have impact on the way you are using the plugins unless there is a very, very specific feature you need.

[EMLLC-Support]

Thanks for the quick response @sebastienlevert . Here’s an ai generated reproducible scenario that shows the issue clearly:

Repro Steps

1. Create a Copilot agent using the @microsoft/typespec-m365-copilot emitter.

2. Run:

   tsp compile . --emit @microsoft/typespec-m365-copilot
   

   This generates the following files in /dist:

   • *-apiplugin.json
   • *-openapi.yml
   • declarativeAgent.json

3. Manually update the generated *-apiplugin.json files to match the v2.3 plugin schema, which requires:

   • schema_version: "v2.3"
   • runtimes with run_for_functions
   • No operationIds, function_map, or api blocks

4. Start debugging or publish the agent using Teams Toolkit.

Observed Behavior

During debug or publish, Teams Toolkit triggers another TypeSpec compile, which overwrites the corrected v2.3 plugin files with the older emitter‑generated format. As a result:

• The agent cannot bind functions to OpenAPI operations
• The agent falls back to the generic “Workflow Actions” stub
• Backend calls never fire
• The agent sends placeholder payloads like workflowId: "intro"

Expected Behavior

A way to preserve the corrected plugin files so the agent uses the v2.3‑compliant versions during debug and publish.

Why This Matters

The current emitter generates plugin files that do not match the v2.3 schema. The only way to get correct behavior is to manually fix the plugin files — but those fixes are overwritten every time the agent is built or published.

[sebastienlevert]

What exact behavior do you require with the 2.3 schema?

[EMLLC-Support]

Hi @sebastienlevert . First off, Happy New Year!

It seems that I was using actions.tsp and api.tsp incorrectly. I also had some decorators applied incorrectly in my main.tsp. file. To make a long story short, I cleaned that up and unnecessary openapi and plugin scripts went away. Now I only have exactly what I need.

I'm good to go now. Thank you so much for your response and sorry to reach out to you on the Christmas break. This issue is resolved.

I'm sure I'll have more questions for you :-)

Cheers

[EMLLC-Support]

Hi @sebastienlevert

Question for you. I am having difficulty getting my agent to flip an identifier based on a backend state indicated in the response body. My backend is working correctly. The problem is when I create an instruction that says something like

When the user indicates they want to begin the consent workflow, interpret that request as referring to the workflow identified as “ack‑qna‑consent” with version “v1”.

it is classified as jailbreak. The agent wants to make up an identifier which I feel is hallucinated because it does not use a consistent identifier nor format.

How do I prompt this so the agent injects the correct identifier value in the request body 100% of the time based on a pre-categorized user intent?

An example of this is listed below:
Pre-initialization is a cool word (success)

Pre-initialization is a workflow (success)

Pre-initialization is a workflow that has a consist workflowId (jailbreak)

[EMLLC-Support]

Hi @sebastienlevert

Not sure what to say other that I've gotten really far in y project. I have a lot of working pieces in place. I've done quite a bit of research. Not sure how to proceed from here as the jailbreak issue is not a clean-cut easy issue to navigate around. Who do I talk to or help?

[sebastienlevert]

I'm not sure what you mean. Can you illustrate with actual examples, the requests it sends to your API (where it might hallucinate IDs), etc.?

[EMLLC-Support]

Hi @sebastienlevert

Thank you for your response.

My current state is I've built my backend state machine and I just revised all my function apps to use sessionId as my partition key in all my containers. I am in the process of re-wiring the instruction block with the following structure:
IDENTITY -
SAFETY & SCOPE
INTENT CLASSIFICATION RULES
RESOLVER SELECTION RULES
WORKFLOW INVOCATION RULES -
RESPONSE SHAPING / RENDERING RULES
BACKEND REALITY / SOURCE OF TRUTH
GENERAL BEHAVIOR RULES

Do you agree with this conceptual evaluation order for my main.tsp instruction block?

Please forgive me if I don't always answer your immediate question. By the time we connect I am often times pretty far ahead in my troubleshooting than where I was when I originally asked the question.

An example in thsi instance is my agent begin with a pre-initializer. Once intent has been classified, he agent agent calls workflow initialization. Theat initialization is supposed to flip workfloweInitialized from false to true, but the agent is supposed to do it. The agent is not doing it. The agent is hellucinating workflowId and sessionId. There were some partition key issues so that potentially could be the cause of silent failure.

In true form, I have rewired my entire backend since my message, and I am now in the process of testing it which will take a few hours. Now sure where I'll be when we reconnect :-)

[sebastienlevert]

I have the impression that your backend service doesn't serve agentic scenarios really well. You should return that data back to the agent and let the agent know that the data is to be used.

[EMLLC-Support]

Check out the attached document @sebastienlevert

This is what I Am haggling with. My research says my backend is set up in a complaint and architecturally sound manner. I have to haggle with the instruction block now.

I need to connect with a wizard who understands the Dos and Don'ts of the instruction block as section placement, order within section, and language matters. As I am sure you already know, the validator is extremely particular and nonsensical on a surface level. I am still learning the language. Until then, I need help

[EMLLC-Support]

but you are correct @sebastienlevert

my prior backend set up was sending malformed payloads. nevertheless., does correcting that remove the jailbreak issues?

[sebastienlevert]

You are telling me that some of these wordings are classified as jailbreaks when using the agent? I don't see anything specific that would really break it

[EMLLC-Support]

Let me get my backend fully updated @sebastienlevert. I was in error when trying to get the agent to do some things and that possibly was the issue. I'll follow up with you next week. Thank you so much for your response and have a great weekend.

[EMLLC-Support]

Ok @sebastienlevert .

I think I am nearing the finish line. For the most part, my instruction block has been stabilized except that now I am having a difficult time binding a value from the prior response body to my proceeding request body. For example, the prior response body incudes questionId value that must be passed to the agents request body questionId value. My backend is fully operational and fully deterministic. when i tets in apim everything works perfectly with the same identical request body. the issue is instruction block.

I used the explicit, and restrcitive, instruction block listed below as an example and the agent still halleucinates the questionId value. How do you recommend binding this value as my backend requires the agent to pass it?

QNA PHASE (Strict Production Mode — Condensed)
When resolveState returns a QnA question, the agent enters the QnA phase.
For every user answer, the agent must call addResponse → resolveState in that exact order. This sequence is mandatory.
addResponse requirements:

• Request body must contain only: sessionId, workflowId, questionId (exactly as returned by the most recent resolveState), and answer.
• The agent must use the backend‑returned questionId exactly as provided.
• The agent must not infer, modify, generate, or substitute any questionId.
• If questionId is missing, the agent must call resolveState first and must not proceed.

resolveState requirements:

• The agent must send the user’s answer using the field "answer".
• The agent must not include "response" or questionId.
• The agent must never skip resolveState.
• The agent must store the questionId only until the next addResponse call and must not persist or reuse stale values.
• The agent must not generate questions; the backend resolver is the sole source of QnA progression.
• The agent must not provide editorial content; all user input must be processed through backend actions.
• The agent must not hallucinate explanations or internal state. Backend errors must be reported exactly as returned.
• The QnA loop is strictly: addResponse → resolveState → next question.

[EMLLC-Support]

@sebastienlevert

Copilot is telling me:
You are not dealing with a backend failure anymore.
You are not dealing with an OpenAPI mismatch anymore.
You are not dealing with a missing field anymore.

You are now seeing pure planner‑level misrouting — and the transcript you posted proves it with absolute clarity.