I know where this is coming from, but lets remember to change them before we remove the draft mode on the RFC

Ack - a493146

General comment:
We are missing here a table of properties and attributes this resource will need/return, but I think it can be added once the L1s are ready.
Additionally, there are some support and helper methods that will target runtime directly, but that don't provide a good explanation and use case example on why they are needed, and how can they be used. For example, the code snippets below explaining how to create the runtime are good, but they suddenly also add a endpoint to it, but we don't explain why or what use case will be solved by doing that. Adding additional sections explaining this helper methods, specially for people that are not fully knowledgable on AgentCore specifics, will give a better understanding of how we want this L2 to work and why

Ack , Added some details for versioning and endpoint. - a493146

Not sure if we need to add this code snippets here, as they can add confusion since this is not really CDK related. If we want to keep them, lets please add a one paragraph explanation, clarifying that his is just an example how you will use the runtime later, once deployed.

Ack, removed this snippet to avoid any confusion.

There are no mentions of Runtime versioning. Is this something we don't plan to support initially?

Runtime versioning is an implicit behaviour of runtime, added some notes for versioning. a493146

This is a good explanation. Can we also add examples how this multi endpoint setup will look like in code?
I am trying to understand how this method will work. From what I can see, and correct me if I am wrong, addEndpoint will assign the endpoint to the latest runtime. But lets say I update that runtime at some point in the future, because I modified something in the configuration. How will the original endpoint be preserved and accessed through CDK? What I imagining that will happen is that since the runtime changed, then we will end up also creating a new endpoint (the "DEFAULT" one) that is targeting the new version of the runtime which is ok, but makes me wonder how can people access or modify the old endpoint.

When you create an endpoint with addEndpoint(), it captures the version at that moment. If you specify a version explicitly, it uses that; otherwise, it uses the runtime's current version. You can use version to point to old endpoint.
I will add some example to RFC.

const publicEndpoint = agentRuntime.addEndpoint('public_endpoint_auth', {
      description: 'Public endpoint for AgentCore runtime access',
      version:"2"
    });

export interface AddEndpointOptions {
  /**
   * Description for the endpoint
   * @default - No description
   */
  readonly description?: string;
  /**
   * Override the runtime version for this endpoint
   * @default - Uses the runtime's version
   */
  readonly version?: string;
}

On a second thought, do you think we should add a function in l2 construct to list all the old versions of a runtime.
boto3 has this -

response = client.list_agent_runtime_versions(
    agentRuntimeId='string',
    maxResults=123,
    nextToken='string'
)

I was confused by this, but now, an also with the table provided above, I get it better. Due to the nature of cdk, listing the version itself in the L2 construct wont work, since this call will be made probably during deployment and at that point you cannot control choosing which version to use, you already made that decision. But lets add this to the documentation both in the JSDoc and in the README file of the module itself, so we let our customers know how to look for existing versions so they can use a diff one than the latest if they need to. But after understanding this, I think this implementation is good enough as it is, we just need to expand the documentation around it

I could be wrong, but I think this clientToken is needed for the initial custom resource implementation, and wont be needed for the L1s. That property is normally needed in direct API calls, but I dont see anything similar now that the L1s for this resource are available

Correct, it has been removed from the current implementation which uses cfn resources, we will update the RFC with the changes

Yes, It is not in CFN anymore, will remove it. Same with concurrencyConfiguration, will remove that too.

Just out of curiosity, can you give a name to the version that is generated, or is it always autogenerated by the service ?

Yes runtime versions are automatically generated when you update the runtime's configuration.

I like this explanation

This is a very nice table. Does this DEFAULT endpoint exists when the moment you create the runtime? lets say I create the runtime in cdk without any specific endpoint, will this default one be created by the create runtime call? and can customers use it to invoke the runtime? In any case, this is good information and explain well the scenario, lets add it to the notes of the README in the alpha module PR if not there already, it will help customers to understand how they can manage their resources

Yes, the DEFAULT endpoint gets created with runtime and you can use it to invoke too.

Ok, makes sense, lets add notes on this, mostly in the readme notes of the alpha module, once the PR of this resource is implemented

Lets add some paragraphs explaining what is this construct for, and some usecases explaining how it can be used, The examples below are great, so lets add a bit of explanation here, to help the user understand when they could use each of them

Done in the local repo and will update the rfc

Ack.

Same as in the Browser tool section, lets add some paragraphs explaining what is this construct for, and some usecases explaining how it can be used, The examples below are great, so lets add a bit of explanation here, to help the user understand when they could use each of them. And lets bring up the Network Modes explanation before the code examples

Ack

This is a very nice table. Does this DEFAULT endpoint exists when the moment you create the runtime? lets say I create the runtime in cdk without any specific endpoint, will this default one be created by the create runtime call? and can customers use it to invoke the runtime? In any case, this is good information and explain well the scenario, lets add it to the notes of the README in the alpha module PR if not there already, it will help customers to understand how they can manage their resources

I was confused by this, but now, an also with the table provided above, I get it better. Due to the nature of cdk, listing the version itself in the L2 construct wont work, since this call will be made probably during deployment and at that point you cannot control choosing which version to use, you already made that decision. But lets add this to the documentation both in the JSDoc and in the README file of the module itself, so we let our customers know how to look for existing versions so they can use a diff one than the latest if they need to. But after understanding this, I think this implementation is good enough as it is, we just need to expand the documentation around it

I am not sure this method adds value. What is the use case we are trying to solve with it? It seems weird to have a constructor for a resource with a param and then call a method to change that param. Considering that in CDK code everything happens at synth time, is this going to create just 1 resource (targeting v2) or is this going to create 2 endpoints, one per each version?

You are right , forgot to remove this, it was there as per the initial plan, but we don't need it now.