fix: docs typos (#33)

Author: aduminuc

docs/README.md

@@ -18,7 +18,7 @@ ACP offers an API to search for the agents served by the ACP server.
 Once a client has an agent identifier `AgentID`, it can use it to either retrieve the agent descriptor or to control agent runs.
 
 #### Retrieve all agents supported by the server
-In this case the client is doing a search of all agents in the server without specifying any search filter. Results is a list of agents.
+In this case, the client is doing a search of all agents in the server without specifying any search filter. Result is the list of all agents.
 
 ```mermaid
 sequenceDiagram
@@ -29,7 +29,7 @@ sequenceDiagram
 ```
 
 #### Retrieve an agent from its name and version
-In this case the client knows name and version of an agent (e.g. learnt from the record in the Agent Directory) and wants to retrieve its `id` to interact with the agent.
+In this case, the client knows name and version of an agent (e.g. learnt from the record in the Agent Directory) and wants to retrieve its `id` to interact with the agent.
 
 ```mermaid
 sequenceDiagram
@@ -40,7 +40,7 @@ sequenceDiagram
 ```
 
 #### Retrieve agent descriptor from its identifier
-In this case the client knows the agent id and wants to retrieve its descriptor to learn about the capabilities supported and the data schemas to use.
+In this case, the client knows the agent id and wants to retrieve its descriptor to learn about the capabilities supported and the data schemas to use.
 
 ```mermaid
 sequenceDiagram
@@ -71,13 +71,13 @@ sequenceDiagram
 ```
 In the sequence above:
 1. The client requests to start a run on a specific agent, providing its `agent_id`, and specifying:
-    * Configuration: a run configuration is flavoring the behavior of this agent for this run
-    * Input: run input provides the data the agent will operate on
-    * Metadata: metadata is a free format object that can be used by the client to tag the run with arbitrary information
-1. The server returns a run object which include the run identifier and a status, which at the beginning will be `pending`.
-1. The client retrieves the status of the run until completion
-1. The server returns the run object with the updated status
-1. The client request the output of the run
+    * Configuration: a run configuration is flavoring the behavior of this agent for this run.
+    * Input: run input provides the data the agent will operate on.
+    * Metadata: metadata is a free format object that can be used by the client to tag the run with arbitrary information.
+1. The server returns a run object which includes the run identifier and a status, the status at the beginning will be `pending`.
+1. The client retrieves the status of the run until completion.
+1. The server returns the run object with the updated status.
+1. The client request the output of the run.
 1. The server returns the final result of the run.
 
 >
@@ -98,10 +98,10 @@ sequenceDiagram
 ```
 
 In the sequence above:
-1. The client requests to start a run on a specific agent
-1. The server returns a run object 
-1. The client request the output of the run providing addition `block_timeout` parameter, and blocs until run status changes or timeout expires.
-1. The server returns the final result of the run. Note that in case the timeout expired before, the server would have returned no content.
+1. The client requests to start a run on a specific agent.
+1. The server returns a run object.
+1. The client request the output of the run providing additional `block_timeout` parameter, and blocks until run status changes or timeout expires.
+1. The server returns the final result of the run. Note that in case the timeout had expired before, the server would have returned no content.
 
 #### Start a Run of an Agent with a callback
 Agents can support callbacks, i.e. asynchronously call back the client upon run status change. The support for interrupts is signaled in the agent descriptor.
@@ -119,16 +119,16 @@ sequenceDiagram
     S->>-C: RunOutput={type="result", result}
 ```
 In the sequence above:
-1. The client requests to start a run on a specific agent, providing an additional `callback`
-1. The server returns a run object
+1. The client requests to start a run on a specific agent, providing an additional `callback`.
+1. The server returns a run object.
 1. Upon status change, the server calls the provided call back with the run object.
-1. The client request the output of the run
+1. The client request the output of the run.
 1. The server return the final result of the run.
 
 ### Run Interrupt and Resume
 Agent can support interrupts, i.e. the run execution can interrupt to request additional input to the client. The support for interrupts is signaled in the agent ACP descriptor.
 
-When an interrupt occurs, the server provides the client with an interrupt payload, which specifies the interrupt type that have occurred and all the information associated with that interrupt, i.e. a request for additional input.
+When an interrupt occurs, the server provides the client with an interrupt payload, which specifies the interrupt type that has occurred and all the information associated with that interrupt, i.e. a request for additional input.
 
 The client can collect the needed input for the specific interrupt and resume the run by providing the resume payload, i.e. the additional input requested by the interrupt.
 
@@ -140,7 +140,7 @@ The interrupt is provided by the server when the client requests the output.
 
 #### Start a run and resume it upon interruption
 
-In this case, the client asks for the agent output and receives and interrupt instead of the final output. The client then resumes the run providing the needed input and finally when run is completed, gets the result.
+In this case, the client asks for the agent output and receives an interrupt instead of the final output. The client then resumes the run providing the needed input and finally when the run is completed, gets the result.
 
 ```mermaid
 sequenceDiagram
@@ -157,12 +157,12 @@ sequenceDiagram
     S->>-C: RunOutput={type="result", result}
 ```
 In the sequence above:
-1. The client start the run
-1. The server returns the run object
-1. The client requests the output
-1. The server returns an interrupt, specifying interrupt type and the associated payload
-1. The client resumes the run providing the needed input in the resume payload
-1. the client requests the output
+1. The client start the run.
+1. The server returns the run object.
+1. The client requests the output.
+1. The server returns an interrupt, specifying interrupt type and the associated payload.
+1. The client resumes the run providing the needed input in the resume payload.
+1. the client requests the output.
 1. The server returns the final result.
 
 ### Thread Runs
@@ -172,14 +172,14 @@ When an agent supports thread run, each run is associated to a thread, and at th
 
 Subsequent runs on the same thread use the previously created state, together with the run input provided.
 
-The server offers ways to retrieve the current thread state and the history of the runs on a thread and the evolution of the thread states over execution of runs.
+The server offers ways to retrieve the current thread state, the history of the runs on a thread, and the evolution of the thread states over execution of runs.
 
 >
 > Note that the format of the thread state is not specified by ACP, but it is (optionally) defined in the agent ACP descriptor. If specified, it can be retrieved by the client, if not it's not accessible to the client.
 >
 
 #### Start of multiple runs over the same thread
-In this case the client starts a sequence of runs on the same threads accumulating a state in the server. In this specific example the input is a chat message, while the state kept in the server is the chat history.
+In this case the client starts a sequence of runs on the same thread accumulating a state in the server. In this specific example the input is a chat message, while the state kept in the server is the chat history.
 
 ```mermaid
 sequenceDiagram
@@ -203,18 +203,18 @@ sequenceDiagram
     S->>-C: ThreadState=[<br/>"Hello, my name is John?",<br/>"Hello John, how can I help?"<br/>"Can you remind my name?",<br/>"Yes, your name is John"<br/>]
 ```
 In the sequence above:
-1. The client starts the first run and provides the first message of the chat
-1. The server return the run object which **includes a thread ID** because the server supports threaded runs
-1. The client requests the run output
+1. The client starts the first run and provides the first message of the chat.
+1. The server returns the run object which **includes a thread ID** because the server supports thread runs.
+1. The client requests the run output.
 1. The server returns the run output which is the next chat message from the agent and leaves a state with the current chat history.
 1. The client starts a new run providing:
-    * The same thread ID, which means that the run will use the existing state associated with the thread
-    * The input for the run, i.e. the next message in the chat (assuming the existence of the server of the chat history)
-1. The server start the runs using the existing chat history and returns the run object
-1. The client requests the run output
-1. The server update the thread state and returns the run output
-1. Finally, the client requests the thread state (this is an optional operation)
-1. The server returns the current thread state which collect the whole chat history
+    * The same thread ID, which means that the run will use the existing state associated with the thread.
+    * The input for the run, i.e. the next message in the chat (assuming the existence of the chat history on the server).
+1. The server starts the runs using the existing chat history and returns the run object.
+1. The client requests the run output.
+1. The server updates the thread state and returns the run output.
+1. Finally, the client requests the thread state (this is an optional operation).
+1. The server returns the current thread state which collects the whole chat history.
 
 ### Output Streaming
 ACP supports output streaming. Agent can stream intermediate results of a Run to provide better response time and user experience.
@@ -241,30 +241,30 @@ sequenceDiagram
     S->>C: StreamEvent={id="2", event="agent_event", data={run_id, type="result", result={"message": "Hello, how"}}}
     S->>C: StreamEvent={id="2", event="agent_event", data={run_id, type="result", result={"message": "Hello, how can"}}}
     S->>C: StreamEvent={id="3", event="agent_event", data={run_id, type="result", result={"message": "Hello, how can I help"}}}
-    S->>C: StreamEvent={id="4",, event="agent_event", data={run_id, type="result", result={"message": "Hello, how can I help you"}}}
-    S->>C: StreamEvent={id="5",, event="agent_event", data={run_id, type="result", result={"message": "Hello, how can I help you today"}}}
+    S->>C: StreamEvent={id="4", event="agent_event", data={run_id, type="result", result={"message": "Hello, how can I help you"}}}
+    S->>C: StreamEvent={id="5", event="agent_event", data={run_id, type="result", result={"message": "Hello, how can I help you today"}}}
     S->>C: Close Connection
     end
 ```
 
 In the sequence above:
-1. The client requests to start a run on a specific agent specifying streaming mode = 'result'
-1. The server returns a run object 
-1. The client request the output streaming and keeps the connection open
-1. The server returns an event with message="Hello"
-1. The server returns an event with updated message "Hello, how"
-1. The server returns an event with updated message "Hello, how can"
-1. The server returns an event with updated message "Hello, how can I help"
-1. The server returns an event with updated message "Hello, how can I help you"
-1. The server returns an event with updated message "Hello, how can I help you today"
-1. The server closes the conenction because the output is complete
+1. The client requests to start a run on a specific agent specifying streaming mode = 'result'.
+1. The server returns a run object.
+1. The client requests the output streaming and keeps the connection open.
+1. The server returns an event with message="Hello".
+1. The server returns an event with updated message "Hello, how".
+1. The server returns an event with updated message "Hello, how can".
+1. The server returns an event with updated message "Hello, how can I help".
+1. The server returns an event with updated message "Hello, how can I help you".
+1. The server returns an event with updated message "Hello, how can I help you today".
+1. The server closes the connection because the output is complete.
 
 ## Agent ACP descriptor
 
 Agent ACP Descriptor is a descriptor that contains all the needed information to know how:
-* Identify an agent
-* Know its capabilities
-* Consume its capabilities
+* Identify an agent.
+* Know its capabilities.
+* Consume its capabilities.
 
 The Agent ACP Descriptor can be obtained from the Agent Directory or can be obtained through an [ACP call](#retrieve-agent-descriptor-from-its-identifier).
 
@@ -312,11 +312,11 @@ Agent Specs section includes ACP invocation capabilities and the schema definiti
 The ACP capabilities that the agent support, e.g. `streaming`, `callbacks`, `interrupts` etc.
 
 The schemas of all the objects that this agent supports for:
-   * Agent Configuration
-   * Run Input
-   * Run Output
-   * Interrupt and Resume Payloads
-   * Thread State
+   * Agent Configuration.
+   * Run Input.
+   * Run Output.
+   * Interrupt and Resume Payloads.
+   * Thread State.
 
 Note that these schemas are needed in the agent ACP descriptor, since they are agent specific and are not defined by ACP, i.e. ACP defines a generic JSON object for the data structures listed above.
 
@@ -439,8 +439,8 @@ Note that these schemas are needed in the agent ACP descriptor, since they are a
 The agent supports threads, interrupts, and callback.
 
 It declares schemas for input, output, and config:
-* As input, it expects the next message of the chat from the user
-* As output, it produces the next message of the chat from the agent
+* As input, it expects the next message of the chat from the user.
+* As output, it produces the next message of the chat from the agent.
 * As config it expects the style of the email to be written.
 
 It supports one kind of interrupt, which is used to ask user for approval before sending the email. It provides subject, body, and recipients of the email as interrupt payload and expects approval as input to resume.