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.